W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Do we kill the "Host:" header in HTTP/2 ?

From: Roberto Peon <grmocg@gmail.com>
Date: Sat, 2 Feb 2013 20:53:03 +0900
Message-ID: <CAP+FsNcLeKAzxPEG-Y7VwPT8pt6kWXmmoJDi0ZNrEDA53bqUhw@mail.gmail.com>
To: Adrien de Croy <adrien@qbik.com>
Cc: James M Snell <jasnell@gmail.com>, Roland Zink <roland@zinks.de>, Julian Reschke <julian.reschke@gmx.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I'll point out that the delta compressor already deals these encoding
problems by using a static dictionary (i.e. O(1) state for program
execution) for key-values, some of which are certainly ":method", "GET",

Thus the various methods get assigned numeric IDs, and if one isn't
familiar, then you can either represent it as text every time, or if the
receiver allows for state storage, it can allocate a new numeric ID after
seeing the method once.

The only thing that isn't "solved" right now is putting the scheme, host,
and path components in whatever combination, at the beginning, mainly
because it makes the state machine for a(ny) compressor significantly more
annoying to manage as it can require that entries in the compression
context get expired.

If we're worried about the bit-width of these things, we can make some of
these "special" and only use a byte to index 'em (thusfar the static
dictionary has ~64 items, so this should be quite safe). Personally, I hate
that idea, and think that 2-bytes to encode this is perfectly fine. :)


On Sat, Feb 2, 2013 at 8:53 AM, Adrien de Croy <adrien@qbik.com> wrote:

> It buys us also the ability to efficiently decipher the method. Currently
> we have to convert the string method name to an enum anyway. Why not just
> start out that way.
> All the byte savings add up.  I think we should consider all the parts of
> the request line incl URI parts to be simply fields in the request, and be
> able to only send new values when they change.
> Default values could be used for various parts as well such as scheme and
> method.
> You never know how significant 2 or 3 bytes may be. It could be the
> difference between needing to split the buffer over more than one packet or
> not.
> Sent from my iPad
> On 2/02/2013, at 10:10, James M Snell <jasnell@gmail.com> wrote:
> What does this buy us? Two or three bytes typically? Not worth it. Just
> send the method name.
> method just isn't a high priority for optimization.
> On Feb 1, 2013 12:33 PM, "Adrien de Croy" <adrien@qbik.com> wrote:
>> Not really.
>> Just reserve a number to indicate the method name is following in text
>> Or reserve a range for private use
>> Could even largely avoid sending method at all.  If it were treated like
>> a field, default to GET you would only need to send if it changed
>> Sent from my iPad
>> On 2/02/2013, at 9:28, Julian Reschke <julian.reschke@gmx.de> wrote:
>> > On 2013-02-01 21:17, Adrien de Croy wrote:
>> >> We see ftp:// all the time
>> >>
>> >> As for using a character or 2 for the method. Why? What is wrong with
>> numbers?
>> >>
>> >> 1 = GET
>> >> 2 = HEAD
>> >> 3 = POST
>> >> etc.
>> >> ...
>> >
>> > Experimenting with new method names becomes really really hard.
>> >
>> > Best regards, Julian
Received on Saturday, 2 February 2013 11:53:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC