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

On Thu, Aug 2, 2012 at 12:59 AM, Mike Belshe <mike@belshe.com> wrote:

>
>
> 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 ability to define header values as UTF-8 would help application
developers in a number of ways... just look at the various inconsistencies
that currently exist in the definitions of standardized headers like
Authorization, Content-Disposition, Link, etc.


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

Um... HTTP headers are extensible. There are new headers popping up all the
time. A registry that changes over time would be ideal and the codepages
mechanism (or other similar must-understand type system) would be essential
to enabling translation back to 1.1. We have to design for the future,
right? ;-)


>  > * 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?
>
>
Again, if there's anything in an HTTP 2.0 message that the intermediary
cannot reliably translate to 1.1 when it needs to, then the intermediary is
free to return a protocol error back to the client. The rational behind
allowing binary values is to eliminate the necessity of applying
ascii-transformations to values and allow for more efficient use of the
transport.


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

I'm not convinced there needs to be a signal for the "last set of
headers"... I've been kicking around a variety of cases where it could make
sense to interleave HEADERS frames throughout the data stream right up
until the FIN is sent. Going to be thinking through it a bit more.

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

"Designing for the future" also means guiding and encouraging developers to
make better choices about what kind of data they go about sticking in
things like Cookies.

- James

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