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: James M Snell <jasnell@gmail.com>
Date: Thu, 31 Jan 2013 23:09:42 -0800
Message-ID: <CABP7RbcEjjtD3eaeZuQ7+KswXHd3FJMKiYMJR2sK51YD3J2epA@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
One proposal on this particular topic...

We can combine the :scheme, :method, :host and :path header fields into a
single :req Header with a compact binary encoding and require that this
single header always appear first in request header blocks.

+------------------------------+
|S|len(method)|method|len(host)|
+-+-------+----+---------+-----+
|   host  | len(path) |  path  |
+------------------------------+

S = Single bit, when set, scheme = https, when not set, scheme = http
len(method) = 7 bit length of method name
method = name of method
len(host) = uvarint(host)
host = host
len(path) = uvarint(path)
path = path

Examples:

GET request for http://example.net/foo would be:

  [03,G,E,T,0B,e,x,a,m,p,l,e,.,c,o,m,04,/,f,o,o]

POST request for https://example.net/foo would be:

  [84,P,O,S,T,0B,e,x,a,m,p,l,e,.,c,o,m,04,/,f,o,o]

Unregistered method 'FOO' request for https://example.net/foo would be:

  [83,F,O,O,0B,e,x,a,m,p,l,e,.,c,o,m,04,/,f,o,o]

If the client chooses not to send a host (because it's not needed or
whatnot) they simply set len(host) to 0...

  [03,G,E,T,00,04,/,f,o,o]

If we do end up going with delta encoding for compression, we can require
that the :req Header always be passed using the eref operation (ephemeral
reference, meaning that the header is never stored in the compression
state). No huffman-coding would be applied to the header, making it very
quick and cheap to process.

Thoughts?

- James



On Thu, Jan 31, 2013 at 8:04 AM, Ted Hardie <ted.ietf@gmail.com> wrote:

> On Thu, Jan 31, 2013 at 5:15 AM, Roy T. Fielding about this
>
> >> We had no idea how early we were in the popularity curve of HTTP or
> >> how dominant it would become, but it was clear even then that the
> >> protocol would be very, very common on the network.  In retrospect, it
> >> is clear that we shouldn't have looked at the current installed
> >> base--we should have looked at what we expected eventual use would be.
> >> That makes "the earlier the better" clear.
> >
> > I think your memory is a bit hazy there ... HTTP passed all
> > application protocols other than email in 1995, and by that
> > time (Mar 1996) was roughly double email traffic, IIRC (this was
> > before email-based spam became common).  That's why the WG
> > meeting contained a lot of people who had nothing to do
> > with developing the Web protocols---there was panic in the air.
> >
>
> I think we can both agree it only got more popular from there.  It may
> well have surpassed email by that discussion, but the hockey stick had
> a lot of run to go.
>
> > I find it amusing that you think we could have proceeded in any
> > other way without relegating the IETF work to the garbage bin.
> >
>
> It would have taken agreement from a lot of people, but the web
> community of the time could have decided then to rev the major
> protocol version for that change.  That suggestion was made.  The IETF
> could not have mandated that.  The IETF *never* gets to dictate
> protocol changes--it didn't have police then and it doesn't now, but
> saying that the buy-in for that change didn't happen doesn't equate to
> saying it could not.
>
> regards,
>
> Ted
> >> For HTTP 2.0, where we can make non-backward compatible changes, I
> >> personally think the right thing to do is to drop the Host: header
> >> (that version shift is what we were waiting for 17 years ago, after
> >> all).  If there are things folks are getting from side-effects of the
> >> Host header (e.g. proxy targeting), we put them into the bin of
> >> potential requirements for HTTP 2.0 *and create mechanisms to meet
> >> those needs*.
> >>
> >> I think Adrien's proposal for extensions to the host header makes
> >> clear that the need isn't perfectly met by the host header in any
> >> case, so mapping out the real aim and meeting that seems like the best
> >> notion to me.
> >
> > Oddly enough, waka separates the scheme+host routing information from
> > the rest of the URI because that works better with multi-argument
> > methods and message-based encryption. *shrug*
> >
> > ....Roy
> >
>
>
Received on Friday, 1 February 2013 07:10:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 February 2013 07:10:32 GMT