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

Based on the feedback, we can change this to...

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

The only change here really is the port field as a uvarint. The path would
contain the full query-string and path detail...

Example: GET https://example.com:443/foo?a=b

  [83,G,E,T,0B,e,x,a,m,p,l,e,.,c,o,m,BB,03,08,/,f,o,o,?,a,=,b]

If some other scheme needs to be specified, a separate :scheme header would
be specified identifying the scheme.

Method names are encoded as text because snumeric identifier or
abbreviation schemes are just going to add complexity for no demonstrated
benefit.

- James



On Thu, Jan 31, 2013 at 11:09 PM, James M Snell <jasnell@gmail.com> wrote:

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