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

Splitting host, path and scheme is a kind of prefix-matching. So yes generic prefix matching is not safe (this is the basic definition of what Deflate do). However restricted prefix-matching is.
So we should find the sweet point in the middle that will allow us to have both good compaction and no security threat.

Hervé.
________________________________
From: Roberto Peon [grmocg@gmail.com]
Sent: Thursday, January 31, 2013 00:04
To: Poul-Henning Kamp
Cc: Ted Hardie; Adrien W. de Croy; Eliezer Croitoru; ietf-http-wg@w3.org; John C Klensin
Subject: Re: Do we kill the "Host:" header in HTTP/2 ?

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<mailto:phk@phk.freebsd.dk>> wrote:
Content-Type: text/plain; charset=ISO-8859-1
--------
In message <
        Remove  "Host: " ${fqdn} CR NL

Which looks like a one byte saving to me ?
<Pcw@mail.gmail.com</a>>,
%20Roberto%20Peon%20writes:<br>
<br>
>Dropping%20the%20host%20header%20will%20inflate%20the%20size%20of%20bytes%20on%20the%20wire,%20to%20the<br>
>detriment%20of%20latency.<br>
<br>
</div>
Really%20?<br>
<br>
I%20thought%20we%20hadn't%20decided%20how%20things%20would%20be%20encoded%20yet,%20so%20how%20can<br>
you%20tell%20?<br>
<br>
As%20far%20as%20I%20can%20see,%20if%20we%20did%20this%20to%20HTTP/1%20with%20no%20other%20changes%20we%20would;<br>
<br>
 %20 %20 %20 %20Add%20 >

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