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

On Thu, Jan 24, 2013 at 4:03 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> On Jan 24, 2013, at 9:01 PM, Nico Williams <nico@cryptonector.com> wrote:
>> 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

As long as each can negotiate all-but-stateful-compression I'm happy.
I'd strongly object to having to forego the other things in order to
forego stateful compression.

Also, while we are this, IMO we should first produce minimal encodings
of headers and values where that's meaningful, *then* add optional
stateful compression.

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

Sure, but that's definitely something that had better have either
minimal encoding... or be statfully compressed.  Ugh.  Of course "no
state here" is a tiny -and therefore reasonable- amount of state.

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

But that's not what I'm after.  I'm after the option to not implement
stateful compression.  I'm not saying the other things have to be
optional to implement -- I might, after further reading, but for now I
don't.

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

See my comment about minimal encodings.  Assuming we have that we'd
still have a sizeable improvement even without stateful compression,
and that would be a reason to want to use HTTP/2.0 without stateful
compression.

Nico
--

Received on Thursday, 24 January 2013 22:18:13 UTC