W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

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

From: James M Snell <jasnell@gmail.com>
Date: Thu, 2 Aug 2012 10:08:53 -0700
Message-ID: <CABP7Rbe_6FRp9KrYDC9UBuqn9XEACjDJkAwQeUdFgy9BkJi_UA@mail.gmail.com>
To: Mike Belshe <mike@belshe.com>
Cc: ietf-http-wg@w3.org
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

>>  > * 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
>> >>
>> >
Received on Thursday, 2 August 2012 17:09:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC