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

Re: Updated Binary Optimized Header Encoding Draft

From: James M Snell <jasnell@gmail.com>
Date: Thu, 4 Oct 2012 12:08:46 -0700
Message-ID: <CABP7RbdDeNQWMP8Jh0+PWVYRfzj-S44AqknXXpWP-NCD7+7sQw@mail.gmail.com>
To: Ashok Kumar <ashokkumar.j@gmail.com>
Cc: Jeroen de Borst <J.deBorst@f5.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Wed, Oct 3, 2012 at 10:04 PM, Ashok Kumar <ashokkumar.j@gmail.com> wrote:

> So according to this, if you need multiple binary encoded values, then the
> values themselves can't contain NUL. If they do, then does framing layer
> take responsibility of escaping it or base-64 encode the entire value?
>
>
Yes, that is one existing limitation of this mechanism that I have not
entirely worked out a great solution for.

fwiw, I'm not yet convinced that bohe is something we absolutely need, I
submitted the draft to contribute concrete thoughts to the overall
discussion. There are certainly many such details that would need to be
considered.


> Also, since its very common that clients get updated/upgraded almost (or
> should I say atleast) once a month, and servers/proxies get upgraded only
> when there are some critical patches, how do the two agree on registered
> headers? (this example may be wrong, but let's say, x-forwarded-for becomes
> Forwarded), What is the behavior if the client/server is sending an ID
> which is beyond what the host knows?
>

The integer values for each header would be established via (and assigned
by) the IANA registry. The behavior when an unknown ID is encountered is no
different than when an unknown header is included in a http/1.1 request or
response. Generally, they will be ignored and passed through untouched.

- James


>
> On Thu, Oct 4, 2012 at 9:32 AM, Jeroen de Borst <J.deBorst@f5.com> wrote:
>
>>  This is very similar to what was done in WAP (WSP 1.x specifically).****
>>
>> ** **
>>
>> See section 8.4 in
>> http://www.wapforum.org/tech/documents/WAP-203-WSP-20000504-a.pdf****
>>
>> ** **
>>
>> Does this have to be re-invented? Are there significant benefits?****
>>
>> ** **
>>
>> Thanks,****
>>
>> Jeroen****
>>
>> ** **
>>
>> ** **
>>
>> *From:* James M Snell [mailto:jasnell@gmail.com]
>> *Sent:* Wednesday, October 03, 2012 10:08 AM
>> *To:* ietf-http-wg@w3.org
>> *Subject:* Updated Binary Optimized Header Encoding Draft****
>>
>> ** **
>>
>> FYI.. I have submitted an updated draft for the proposed Binary Optimized
>> Header Encoding mechanism for the http2 effort. ****
>>
>> ** **
>>
>>   http://www.ietf.org/id/draft-snell-httpbis-bohe-01.txt****
>>
>> ** **
>>
>> A number of fairly significant changes have been made:****
>>
>> ** **
>>
>>   1. The codepage identifier for registered header tokens has been
>> removed.****
>>
>>   2. The Per-header flags field has been removed and replaced with
>> specific individual bits to indicate character-based values and multiple
>> values****
>>
>>   3. Value lengths have been increased from max 16-bit length to a max
>> 22-bit length. ****
>>
>> ** **
>>
>> The encoding itself remains just as compact with these changes. With the
>> http version header field, for example, requiring no more than 6
>> uncompressed bytes to represent.****
>>
>> ** **
>>
>> As always, feedback is more than welcome.****
>>
>> ** **
>>
>> - James****
>>
>
>
>
> --
> .- ... .... --- -.-
>
Received on Thursday, 4 October 2012 19:09:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 4 October 2012 19:09:37 GMT