OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-taxii message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cti-taxii] Protocol Shortlist - Add HTTP


Dumb question – what has to change in application code if HTTP/2 is used?

 

Asking the question another way – if I write a Python/Django web app for HTTP/1.1 that runs on Apache, what modifications would I need to make in order to support Apache’s HTTP/2 functionality?

 

Based on what I’ve read, it sounds like application code will have to change very little, if at all. There is a presumption that due to the similarities between HTTP/1.1 and HTTP/2, thigs like Django (or the underlying WSGI) won’t need to change their interface very much, and therefore will have minimal impact to application developers.

 

As I understand it, HTTP/2 adds some new features (Server Push and Stream Prioritization) that will eventually propagate up to the web developer level, and other features (e.g., binary encoding) will be handled transparently by the underlying webserver.

 

This was based on a few minutes of internet searching, so please let me know what I got wrong.

 

If my assumptions are correct, it seems we can for the most part proceed with a general notion of HTTP and then make a value decision about HTTP/1.1 vs HTTP/2 later on.

 

Thank you.

-Mark

 

From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
Sent: Tuesday, August 25, 2015 5:21 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Davidson II, Mark S <mdavidson@mitre.org>; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Protocol Shortlist - Add HTTP

 

I can go with HTTP/2 and that might even solve more of our problems and help us look slightly more progressive without the scary factor.  So as of right now we have two options for a protocol...

 

            HTTP/1.1

            HTTP/2

 

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Aug 25, 2015, at 12:21, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

 

I think HTTP/2.0 should be on the short list as well, as it also meets all the requirements, and enables various additional capabilities.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<graycol.gif>"Davidson II, Mark S" ---2015/08/25 02:57:00 PM---All, As I mentioned in a previous email, not having a protocol to work with has ended up slowing dow

From: "Davidson II, Mark S" <mdavidson@mitre.org>
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/08/25 02:57 PM
Subject: [cti-taxii] Protocol Shortlist - Add HTTP
Sent by: <cti-taxii@lists.oasis-open.org>





All,

As I mentioned in a previous email, not having a protocol to work with has ended up slowing down prototype work. IMO, a shortlist of protocols needs to be picked for prototyping efforts, and I’d like to start that by proposing HTTP be added to the shortlist. That will unblock me so I can write some code that does something. I think HTTP meets our requirements and also works well with Sergey’s idea of incremental change.

Here’s my take on how HTTP stacks up to the protocol requirements we’ve written down so far [1]:

> 1. Minimal changes to existing firewall deployments
AFAIK, just about every FW everywhere let’s HTTP and HTTPS through, so I think this one is met.

> 2. Robust ecosystem of TAXII Server platforms
There are lots of platforms (Web Servers, Messaging Products, etc) that support HTTP or have HTTP interfaces. I’d go as far as to say that I don’t think choosing HTTP would preclude any technology stack that I’ve been exposed to.

> 3. Ubiquitous, well supported client libraries.
HTTP has libraries in every language on just about every platform that I know about.

> 4. Well understood by the software development community
HTTP is IMO the best understood protocol by the development community.

> 5. Supportable in cloud infrastructures
HTTP is used widely in cloud infrastructures

> 6. Integration within existing vendor communication channels
I can’t really speak to this one – somebody else will have to chime in.

> 7. Ability to push information from a server to a client
This is where native HTTP doesn’t work great. Though perhaps a workaround like long polling could be sufficient.

> 8. Protocol efficiency / minimal verbosity
I don’t have any experience or information to make an assessment here.

Please note that this does not represent a group consensus, merely that HTTP is being explored further. Absent dissenting opinions, I’ll work on an HTTP-based prototype and share something about it before too long.

Are there other protocols that should be added to the shortlist?

Thank you.
-Mark

[1] https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Requirements#protocol-requirements

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]