Re: FYI... Binary Optimized Header Encoding for SPDY

On Wed, Aug 1, 2012 at 10:51 PM, James M Snell <jasnell@gmail.com> wrote:

>
> On Aug 1, 2012 8:30 PM, "Mike Belshe" <mike@ <mike@belshe.com>belshe.com<mike@belshe.com>>
> wrote:
> >
> > A couple of thoughts:
> >
> > * Thanks for writing up!
> >
> > * I don't think we need utf-8 encoded headers.  Not sure how you'd pass
> them off to HTTP anyway?
> >
>
> The hand off to http 1.1 could be problematic, yes and I'm not 100% sold
> on the utf-8 thing yet either. It's not an impossible problem tho and
> shouldn't be too much of a challenge since most of the existing header
> value definitions would likely not be modified... that is, just because
> utf-8 is allowed in general doesn't mean that the existing value
> definitions would all automatically be changed to allow for all possible
> utf-8 characters.
>

I just don't see any problem being solved by adding this?  If there is no
benefit, we should not do it, right?


> > * The codepages seem like complexity, but I'm not sure the benefit.  I
> would remove them.
> >
>
> The code pages are specifically *because* of the http 1.1 handoff and the
> need to continue supporting extensibility of headers. If an intermediary
> happens across a code page zero header that it does not understand, and
> therefore cannot translate to an appropriate http 1.1 style header, a
> protocol error can be returned.
>
Why would there be a code page zero header that it doesn't understand?  We
don't want a registry here which changes over time - those are nightmares
to maintain.  However, a static translation could work, which is what I
thought you had with the known headers and the extensible headers. The code
pages aren't necessary to make this work - and seem to just add unnecessary
partitioning.


>  > * I would remove the flags too - per header flags - do we really need
> it?  I'd remove it without a very clear use case.
> >
>
> The immediate use cases are documented within the draft already: binary
> header values and multiple values.
>
One was for utf8, which I think we could nix.  I'm not sure why we need the
binary/multivalue flags - what feature is this for?   I don't see why we'd
want this - its not like you can pass binary data up to HTTP anyway?



>  > * I know that 32bits seems like a lot.  Defining length fields has two
> routes:  fixed length or variable length.  I like the fixed length because
> I believe they are simpler.  However, the price of that simplicity is that
> you've got limits.  Everyone hates limits :-)  In your proposal you whacked
> the number of headers to 8 bits, or 256 headers.   While I agree this is an
> edge, I don't see a reason why it should be against the rules to have more.
>  Same for the length of a header value - you've used 16 bits (64KB).  While
> this seems massive by today's standards, in 10 years maybe 1MB cookies are
> the norm.  I don't know, but I'd hate to have the limit.  So.... this
> leaves us thinking that maybe we should use variable length encoding.
>  Personally, I think the fixed length simplicity is worth it.  But this is
> subjective, of course.   Just use 32bits everywhere - it works well and you
> won't notice the perf difference at all (I measured :-)
> >
> >
>
> If you need more than 256 headers, use multiple HEADERS frames. There is
> no limit to the number of HEADERS frames you can send so that should cover
> your edge case.
>
> I can live with that; there might be a sentinel issue here - when did you
get the last set of headers.

> And I would argue that anyone who is using header values longer than
> max(int16) Is Doing It Wrong.
>
I disagree.  If you had a 1Gbps line to your phone and a 1Tbps line to your
house, a 100KB cookie might be just great...  we have to design this for
the future.


>  Variable length encoding would be a mistake because it's simply not
> necessary.
>
I don't like it either.  But compressing the 32bits to 16bits is a poor
trade.  Just make it work.  This level of compression won't have an impact
on performance, but will have an impact on how the protocol evolves.

Mike



- James
>
> >
> >
> >
> > On Wed, Aug 1, 2012 at 5:37 PM, James M Snell <jasnell<jasnell@gmail.com>
> @ <jasnell@gmail.com>gmail.com <jasnell@gmail.com>> wrote:
> >>
> >> I have submitted an I-D describing the alternative header encoding for
> SPDY that I discussed previously. Should be pretty self-explanatory and
> there are plenty of examples given throughout. I know it still has yet to
> be decided whether SPDY will be the starting point for the HTTP/2.0 effort,
> but I wanted to make this available for discussion.
> >>
> >> http <http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>://<http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>
> www.ietf.org <http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>/<http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>
> id <http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>/draft-<http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>
> snell <http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>-<http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>
> httpbis <http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>-<http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>
> bohe <http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>-00.<http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>
> txt <http://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt>
> >> http <http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>://<http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>
> tools.ietf.org <http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>/<http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>
> html <http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>/draft-<http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>
> snell <http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>-<http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>
> httpbis <http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>-<http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>
> bohe <http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>-00<http://tools.ietf.org/html/draft-snell-httpbis-bohe-00>
> >>
> >> - James
> >>
> >
>