W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Should Web Services be served by a different HTTP n+1?

From: Yoav Nir <ynir@checkpoint.com>
Date: Thu, 24 Jan 2013 22:03:58 +0000
To: Nico Williams <nico@cryptonector.com>
CC: Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <4613980CFC78314ABFD7F85CC302772111990734@IL-EX10.ad.checkpoint.com>

On Jan 24, 2013, at 9:01 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Thu, Jan 24, 2013 at 12:41 PM, William Chan (ι™ˆζ™Ίζ˜Œ)
> <willchan@chromium.org> wrote:
>>> The main one is that the receiver has to have enough memory to store the
>>> dictionary.
>> I think this boils down to the argument on the other thread. Do the
>> gains for keeping state outweigh the costs? Note that given Roberto's
>> delta compression proposal, the sender can disable compression
>> entirely, so the receiver does not need to maintain state. Browsers
>> probably would not do this, due to our desire to optimize for web
>> browsing speed. For web services where you control the client, you
>> indeed would be able to disable compression.
> IMO we need stateful compression to be absolutely optional to
> implement.  (If we choose to go with stateful compression in the first
> place.  I think we shouldn't.)

I think we need to do a little more. I think we should define a "minimal implementation" and have a way for client and server to signal this. A minimal implementation would not be able to do any or some of these:
 - compression
 - server-initiated streams
 - stream priority
 - credentials
 - all but a small set of headers.
 - multiple concurrent streams

Maybe we need a CAPABILITIES control frame that will allow client or server to communicate to the other what capabilities they don't have.

A truly minimal client would be capable of one stream at a time - really down to HTTP/1.0 functionality with the new syntax.

Would this allow Phillip to use HTTP/2 for minimalist web services?


Received on Thursday, 24 January 2013 22:04:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC