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

I wouldn't stop there.

* split querystring into individual tuples as well and put them in a 
querystring sub-section.
* deprecate %encoding (no longer needed since nothing is parsed)

Adrien




------ Original Message ------
From: "Roberto Peon" <grmocg@gmail.com>
To: "RUELLAN Herve" <Herve.Ruellan@crf.canon.fr>
Cc: "Poul-Henning Kamp" <phk@phk.freebsd.dk>; "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>
Sent: 31/01/2013 1:45:33 p.m.
Subject: 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.
>>
>