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: Wed, 30 Jan 2013 15:04:24 -0800
Message-ID: <CAP+FsNchuV1V2+deWTwRBC5RkmzV29QjKAM1z+pWVYZaorYUyg@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Ted Hardie <ted.ietf@gmail.com>, "Adrien W. de Croy" <adrien@qbik.com>, Eliezer Croitoru <eliezer@ngtech.co.il>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, John C Klensin <john-ietf@jck.com>
The only thing we know if safe from CRIME attacks is whole-atom matching--
prefix matching is not safe.
So, if we have a host header and a path component and a scheme component,
the scheme and the host won't have to be repeated in a CRIME-safe
encoder/compressor. If it is all one string, either it has to be special
cased (in which case it still ends up being host, path, scheme on the
wire), or we are disallowed from doing compression for it.

I'll point out that it is extremely rare for the whole URL to match a prior
URL, and it is extremely common for the scheme and the host to remain
constant across a large number of queries.


I'm not sure I understand the part where you say that you'd have to
text-process the entire headers to find the fqdn. I think that is assuming
that something like the first-line is preserved as-is, which is not how I
understand things are working out right now (that would throw out
compression on those entries).

Sending the components of the URI separately reduces the need to parse
these things, and better, since most of the time the host won't have
changed, a simple single 'if' allows us to proceed with the fqdn of the
previous request without any parsing at all.

Assuming that we end up with some kind of compressor that only sends what
has changed, in fact, one gets to reuse parsed state, eliminating any need
for parsing at all...
-=R


On Wed, Jan 30, 2013 at 2:55 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> Content-Type: text/plain; charset=ISO-8859-1
> --------
> In message <
> CAP+FsNfGocr9S992SQNWfW+K9Rz5f1XZcVkC7AoV5WXmxF+Pcw@mail.gmail.com>,
> Roberto Peon writes:
>
> >Dropping the host header will inflate the size of bytes on the wire, to
> the
> >detriment of latency.
>
> Really ?
>
> I thought we hadn't decided how things would be encoded yet, so how can
> you tell ?
>
> As far as I can see, if we did this to HTTP/1 with no other changes we
> would;
>
>         Add  "http://" ${fqdn}
>
>         Remove  "Host: " ${fqdn} CR NL
>
> Which looks like a one byte saving to me ?
>
> >I haven't yet heard of a real performance advantage for dropping it. Is
> >there one?
>
> High-performance implementations would not have to text-process the entire
> header to find the fqdn they use for routing decisions.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
Received on Wednesday, 30 January 2013 23:04:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 23:04:55 GMT