Re: Benjamin Carlyle http 2.0 expression of interest

On Sun, Jul 22, 2012 at 2:27 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 23/07/2012 4:20 a.m., Roberto Peon wrote:
>
>
>>
>> On Jul 22, 2012 1:54 AM, "Benjamin Carlyle" <benjamincarlyle@soundadvice.
>> **id.au <benjamincarlyle@soundadvice.id.au> <mailto:benjamincarlyle@**
>> soundadvice.id.au <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?


What kind of numbers are you looking for? I'm not sure what numbers would
make sense. But I guarantee you it is absolutely necessary. A summary of
the NAT connection timeout issue can be found at
http://code.google.com/p/chromium/issues/detail?id=27400. We "fixed" it for
Chromium (before mobile versions were released) by just turning on TCP
keepalive, which is a horrible hack that doesn't work on mobile because it
wakes up the radio. The problem exists in HTTP/1 too, but the pain is
mitigated due to generally speaking only single request/response pairs over
a single TCP connection (which also means reloads would often use a
different TCP connection that worked). For a multiplexed protocol where you
are trying to share a single connection, a dead connection that isn't
detectable at the application layer results in a horrible user experience.


>
>
>  >
>> > #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
>
>