Re: Benjamin Carlyle http 2.0 expression of interest

On Jul 22, 2012 1:54 AM, "Benjamin Carlyle" <
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.
>
> #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.
>
> #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.
>
> #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.
>
> #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.
-=R

>
> That's probably enough of a wishlist for my first post to this list.
Comments/criticism welcome.
>
> Benjamin