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

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 codepages seem like complexity, but I'm not sure the benefit.  I
would remove them.

* I would remove the flags too - per header flags - do we really need it?
 I'd remove it without a very clear use case.

* 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 :-)





On Wed, Aug 1, 2012 at 5:37 PM, James M Snell <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://www.ietf.org/id/draft-snell-httpbis-bohe-00.txt
> http://tools.ietf.org/html/draft-snell-httpbis-bohe-00
>
> - James
>
>