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: Phillip Hallam-Baker <hallam@gmail.com>
Date: Thu, 24 Jan 2013 17:28:39 -0500
Message-ID: <CAMm+Lwj61=gTxgUgGo=P2XNUE2odB++7V_Zu48jhZp+aUWhf8Q@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Yoav Nir <ynir@checkpoint.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>

What I want is to have the simplicity of coding the parser that comes from
being able to use a tokenized encoding. I do want to move away from text
headers but moving from there to a compression library would be total
nonsense for my applications.

Excluding the URI, my applications have four lines of headers. The way I do
compression is by not sending data I don't need.

I want to have better framing and streams etc. So there is a lot in HTTP 2
that would attract me but header compression is a show stopper no matter
how it is polished.

On Thu, Jan 24, 2013 at 5:17 PM, Nico Williams <nico@cryptonector.com>wrote:

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

Website: http://hallambaker.com/
Received on Thursday, 24 January 2013 22:29:07 UTC

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