- From: Roberto Peon <grmocg@gmail.com>
- Date: Wed, 30 Jan 2013 15:04:24 -0800
- 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>
- Message-ID: <CAP+FsNchuV1V2+deWTwRBC5RkmzV29QjKAM1z+pWVYZaorYUyg@mail.gmail.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 UTC