Re: Benjamin Carlyle http 2.0 expression of interest

On 23/07/2012 4:20 a.m., Roberto Peon wrote:
>
>
> On Jul 22, 2012 1:54 AM, "Benjamin Carlyle" 
> <benjamincarlyle@soundadvice.id.au 
> <mailto:benjamincarlyle@soundadvice.id.au>> wrote:
> >
> > This is an individual submission towards the http/2.0 protocol.
> > My background is mostly in highly available soft real-time m2m use 
> cases for http, rather strict browser-centric or Web-centric use 
> cases. Http/1.1 provides a good basis for these use cases but has a 
> number of deficiencies I would hope could be corrected for the new 
> protocol revision.
> >
> > #1 Message level signatures
> > Transport level security provides privacy and non repudiation at the 
> penalty of denying intermediaries the right to inspect messages and 
> otherwise be involved in a transaction. Message level security 
> measures could bring about specific benefits for http in relation to 
> REST and practical use cases. For example:
> > A signed representation could be returned by a cache without 
> introducing man in the middle attacks, particularly if the 
> intermediaries are able to add their own metadata to an envelope that 
> contains the original unmodified and signed body and headers from the 
> origin server.
> > A signed request could eliminate the need for existing 
> authentication mechanisms and allow a message to be authenticated 
> without the need for additional round trips between client and server.
> > Signed messages could be inspected by firewalls to prevent requests 
> being sent that contravene local policy.
> > An encrypted response that can be read only by its intended 
> recipients could in theory even be returned to arbitrary clients 
> without needing to first authenticate them.
> > I think that signatures would significantly simplify m2m use cases. 
> Encryption may also be of use, although it is less important in my 
> particular use cases.
> > Transport level encryption can work against goal of allowing 
> intermediates to inspect and be involved in transactions.
> >
>

See my answer to #4 below. Signing and integrity meta alterations to the 
content can be considered just another form of encoding at the protocol 
level.

Signing and integrity of the message headers is a very difficult problem 
being discussed in another thread at present.


> > #2 Canonical form or info set
> > The signature and encryption issues may be the tip of a larger 
> canonicalization ice berg. HTTP has traditionally allowed new headers 
> a level of freedom in defining both semantics and parsing rules. As we 
> move forwards perhaps it is time to place some limits on this.
> >
> > #3 Out of order responses and heartbeat capability
> > Modifying http to be able to make efficient use of a single TCP 
> connection is I think a priority for many members of this list, and is 
> something that SPDY has been specifically developed to address. I 
> would like to expand on this with the specific notion of heartbeats to 
> be able to reliably answer the question: Is my connection alive or 
> dead? If the connection is dead the client will want to know as 
> quickly as possible so that it can connect to a redundant instance of 
> the server.
>
> The PING frame in SPDY addresses this, btw. It is especially important 
> for clients behind NATS.
>
> > In my use cases I often want positive confirmation that my 
> connection is still valid approximately every four seconds, plus 
> assurances from intermediates that they are also seeing heartbeats.
>
> Keep-alive pings are very to distinguish from DoS attacks. Having the 
> server interpret something once every 4 seconds is probably OK at the 
> layer above the protocol layer.
>
> > For long poll use cases this can be taken care of by requesting a 
> short timeout in requests and for long database transactions a slow 
> response can be replaced by an asynchronous interaction, but it would 
> be helpful to have the server send regular updates on the processing 
> status for a given request. A regular high priority OPTIONS * request 
> may suffice to solve this problem.
>

I'm not sure how useful this is really. Given that multiplexing will 
"fill the pipe" a lot better than HTTP/1 ever did. Does anyone from SPDY 
have actual numbers on how frequently PING frames are really needed?


> >
> > #4 consider replacing internet media type identification model
> > A bit of a wishlist item, but mostly self explanatory. As far as m2m 
> use cases go a typical company might need to mint dozens or more media 
> types for internal use without coordination with the IANA, and it 
> would be good to allow a url that refers to the type's specification 
> or allow a combination of centrally registered tokens and urls as per 
> RFC 5988's link relation registry.
>

+1.

While playing with network-friendly header optimizations we looked at 
merging the Content-Type + Content-Encoding + Transfer-Encoding headers 
meta data into a simple unified syntax.

The result would look like: "Content-Encoding: text, html, gzip, aes"  
to describe a AES signed compressed HTML document. Each hop along the 
way could perform its own encoding/decoding to improve efficiency and 
the header received by the client would describe both the received 
entity and steps required to decode it to something usable.

Notice how integrity data (AES) is just a layer of encoding on the 
entity, irrelevant to the protocol itself and to any network software 
relaying the message. One could also add signatures on the HTML level as 
well, *inside* the gzip if the HTML was important to retain integrity 
but compression method was not. eg. "Content-Encoding: text, html, aes, 
gzip"

Or for the super paranoid: "Content-Encoding: text, xml, sha1, md5, aes, 
foo, gzip, aes, sha1, md5, xz"

> >
> > #5 A must understand model
> > Currently if a new feature is added to http requests that must be 
> understood servers the client must use a new http method to ensure 
> that a server who does not understand will reject the request. Perhaps 
> it is time to introduce a more refined model. My thinking is a must 
> understand header that consists of tokens/urls stating special 
> requirements the server must fulfil before accepting the message for 
> processing. The client could include an additional header that 
> indicates its own supported features to allow the server to tailor its 
> own processing or potentially reject the request.
>

This was tried with Expect. It broke rollout of new features in a lot of 
areas. Software lifetimes at the deeper levels of the network is 
measured in cycles of 5-10 years. They simply wont be able to keep up 
with new header/feature additions. At present they can at least 
pass-thru by default.

> >
> > #6 An idempotent POST
> > It would be helpful to have a way to idempotently POST new state. My 
> preference would be for the client to be able to supply a unique 
> identifier as part of its request that can be used by the server to 
> ignore repeated instances of the message, preferably as a uuid or guid 
> in uri form or other unique uris.
>
> This would require an API change for browsers if this was exposed to 
> webapp designers as well.
>

How does this differ from GET with query string and entity?
The base portion of the URL is the processor script/app address and the 
query portion of the URL is a UUID within that particular URI processor 
space. Together they form a GUID.

In order to be idempotent the URI alone must be able to be used by 
caches to produce a correct response without the entity being even received.

When you have a client implementation that is tied so closely together 
with the server that it can identify what UUID generation algorithm the 
server will be using AND the data points the server will use to generate 
it. You can make any request idempotent with ETag and If-* conditionals.


   POST /foo HTTP/1.1
   If-None-Match: "something"
   ETag: "something"


Amos

Received on Sunday, 22 July 2012 21:28:00 UTC