- From: Roberto Peon <grmocg@gmail.com>
- Date: Sun, 22 Jul 2012 22:39:33 -0700
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: ietf-http-wg@w3.org
- Message-ID: <CAP+FsNdSCQ_ctGdNzM7KUmmrHjz4Ky3JcUM7aYQY2R9HaZE+XA@mail.gmail.com>
For mobile devices it is pretty important. -=R On Jul 22, 2012 2:30 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? > > > > >> > #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 Monday, 23 July 2012 05:40:02 UTC