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

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.

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

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

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

And I would argue that anyone who is using header values longer than
max(int16) Is Doing It Wrong.

Variable length encoding would be a mistake because it's simply not
necessary.

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