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

Scheme,host, and path separation is a good compromise (imo, of course)
because it leaks no information that anyone wouldn't have already been able
to get earlier.

-=R


On Wed, Jan 30, 2013 at 4:08 PM, RUELLAN Herve
<Herve.Ruellan@crf.canon.fr>wrote:

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