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: Adrien W. de Croy <adrien@qbik.com>
Date: Fri, 01 Feb 2013 10:25:47 +0000
To: "Amos Jeffries" <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <em21b5c00f-6f56-4671-b498-5a198dc090e9@bombed>

>From a compressibility / redundancy reduction standpoint, it makes sense 
to have the parts of the URI able to be individually addressed within 
the frame, in a similar way to the other fields.

There are many sites where every page is just index.php?id=xxxx with 
differing values for xxxx

Also why transmit the host every request when it hardly ever changes.

Therefore sending an aggregated URI, which needs to be parsed at the 
other end (or in the middle) is an idea I don't like.

Even if it makes it simpler to do URI-based routing decisions, well I'm 
not convinced that is a good enough reason.  Mostly I would expect 
switching to be done on the host part anyway.

It also doesn't make much sense to send methods as textual names.  A 
simple byte would do, reserving the value of 0xFF to indicate a textual 
name follows.  All other values being registered methods.  If 256 
methods aren't enough, maybe we need to re-evaluate our designs.  There 
could even be more information coded into method binary values, like 
reserving a bit in it for "safety" or "idempotency" or one for 
"invalidates cache" or "can have body" etc so that an intermediary need 
not necessarily understand the method to know what to do with it.


------ Original Message ------
From: "Amos Jeffries" <squid3@treenet.co.nz>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 1/02/2013 10:47:50 p.m.
Subject: Re: Do we kill the "Host:" header in HTTP/2 ?
>On 1/02/2013 8:09 p.m., James M Snell 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.
>>| 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
>This makes several assumptions which are false and will cause a lot of 
>  1) scheme of URI is always http(s)://.
>  2) port is always the default scheme port.
>  3) there is never a query string attached
>  4) there is never a fragment attached
>It also ignores that abomination otherwise known as the '*' URI.
>IMHO, this is a good loss, we could require OPTIONS method on the '/' 
>URI with the current machines hostname or IP do the equivalent and save 
>some parser complexity + CPU checking the * cases on every request.
Received on Friday, 1 February 2013 10:26:36 UTC

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