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

+1

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/