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

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Jan 2013 09:10:01 +0000

Both RFC2616 and the current -bis draft, have text to this effect:

   To allow for transition to the absolute-form for all requests in some
   future version of HTTP, HTTP/1.1 servers MUST accept the absolute-
   form in requests, even though HTTP/1.1 clients will only send them in
   requests to proxies.

Are we going to do that in HTTP/2.0, get rid of the Host: header and
mandate absolute form URIs ?

Doing so will have measurable and structural impact on the various
attempts at space-reduction, so it might be a good idea to make this
decision up front ?

It would also save a lot of text in whatever p1:5.4 becomes in HTTP/2.0.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 30 Jan 2013 01:14:33 -0800

Not as far as I know.
-=R

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Jan 2013 09:18:15 +0000

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <CAP+FsNdk=[email-masked]>, Roberto Peon write

>Not as far as I know.

Why not ?

If if because we havn't thought about it, shouldn't we think about it now ?

---

From: Roberto Peon <[email-masked]>
Date: Wed, 30 Jan 2013 01:20:21 -0800

I'm saying that we're not currently talking about killing the host header.
Are you suggesting that it should be killed?
On Jan 30, 2013 6:18 PM, "Poul-Henning Kamp" <[email-masked]> wrote:

> In message <CAP+FsNdk=
> [email-masked]>, Roberto Peon
> write
> s:
>
> >Not as far as I know.
>
> Why not ?
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Jan 2013 09:31:41 +0000

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <[email-masked]>, Roberto Peon write

>Are you suggesting that it should be killed?

My inclination is that it should, and the text in RFC2616 seems to hint
that others have tagged its existence as a mistake already long time ago.

I also don't spot any obvious down sides if we remove it.

Given that the conversion rules for {abs} <--> {rel+Host} has already
been laid down firmly many years ago, it will not raise any isses
for HTTP/1 <--> HTTP/2 conversion.

It unifies an aspect of the "proxy-version" and the "server-version"
of the protocol, that can't but help make clients code simpler.

And it would make HTTP/2 a speed improvement over HTTP/1 since all the
"routing" information load-balancers need, will be collected in
one place and up front.

And, not the least:  It is certainly easier to explain clearly.

---

From: Roland Zink <[email-masked]>
Date: Wed, 30 Jan 2013 10:34:50 +0100

> And, not the least:  It is certainly easier to explain clearly.
+1

---

From: Roberto Peon <[email-masked]>
Date: Wed, 30 Jan 2013 01:34:46 -0800

The biggest downside is that we'll have to mention the host in an
effectively non-compressible field on every request.

Also, on a number of requests, the host: header differs from the host which
is contained in the URL, and server implementations are not heavily
weighted towards one behaviour or another. It is by far easiest when this
happens to just pass it through and let the server continue to do whatever
it did before...

-=R

On Wed, Jan 30, 2013 at 1:31 AM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <
> [email-masked]>,
> Roberto Peon write
> s:
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Jan 2013 09:40:01 +0000

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <CAP+FsNfwh54JuudVgYPoendwFRvYDoWpXH64GA5iCG_8=[email-masked]>, Roberto Peon write

>effectively non-compressible field on every request.

Why would the URI be more or less non-compressible than the Host: header ?

As I see it, we save a header field, and any compression or optimization based
on prefix matching will have an easier time with one field than with two
fields ?

And if you mean that the URI should not be compressed for performance reason,
in HTTP-routers, I would argue that the same holds, possibly even more so,
for the Host: header...

>is contained in the URL [...]

That would be in direct contravention of the standard:

   [2616, 5.2]:

   1. If Request-URI is an absoluteURI, the host is part of the
      Request-URI. Any Host header field value in the request MUST be
      ignored.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 30 Jan 2013 23:03:06 +1300

On 30/01/2013 10:34 p.m., Roland Zink wrote:
>> In message 
>> <[email-masked]>, 
>> Roberto Peon write
>> s:
>>

Indeed. +1 on all the above.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jan 2013 11:07:44 +0100

On 2013-01-30 10:10, Poul-Henning Kamp wrote:
> ...

Of course we do. It's in 1.1 just to make the transition from 1.0 
simpler. With a completely new header encoding, this issue will go away.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jan 2013 11:23:29 +0100

> simpler. With a completely new header encoding, this issue will go away.

Let me rephrase that...

What we should get rid of is the approach of separating the host 
information into a regular header field.

It needs to be placed either into the request-URI, or next to it.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Jan 2013 10:26:08 +0000

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <[email-masked]>, Julian Reschke writes:

>Of course we do. [...]

So, next question:  Which of the encoding/compression efficiency
numbers we have seen so far have taken this into account, which
needs to be rerun ?

---

From: Patrick McManus <[email-masked]>
Date: Wed, 30 Jan 2013 23:19:04 +0900

> Why would the URI be more or less non-compressible than the Host: header ?
CRIME prevents partial matches of header values (espeically ones that can
contain sensitive information like a URI).. breaking out less sensitive
elements of that like host and scheme will provide greater opportunity for
delta matches. (as julian notes they can all be required to be provided
contiguously and in defined order up front, which I hope helps).

---

From: Nico Williams <[email-masked]>
Date: Wed, 30 Jan 2013 10:35:33 -0600

+1 to killing the Host URI and making sure that either or both of a)
compression for the Request-Line and/or b) measure the existing
compression schemes' ability to compress the Request-Line.

Nico
--

---

From: Eliezer Croitoru <[email-masked]>
Date: Wed, 30 Jan 2013 20:49:57 +0200

>> And, not the least:  It is certainly easier to explain clearly.
+1 for all the above.

-- 
Eliezer Croitoru

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 30 Jan 2013 21:31:01 +0000

from a proxy POV, it's very useful, nay vital that we can tell the 
difference between a request that a client thinks it is sending to a 
proxy, vs a request the client thinks it is sending to a server.

Personally I would be very happy to drop the host part of the URI, and 
keep the host header, but have another flag somewhere that identifies 
the request as one being made to a proxy.

Especially for authentication purposes, the 2 need to be distinguished.

In fact for authentication, I would extend it to allow for the 
definition of the target of the auth.  If you have a request going 
through a chain, and several links require auth from the client, there's 
currently no way to do it safely.

Adrien

------ Original Message ------
From: "Eliezer Croitoru" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 31/01/2013 7:49:57 a.m.
Subject: Re: Do we kill the "Host:" header in HTTP/2 ?
>-- Eliezer Croitoru

---

From: Nico Williams <[email-masked]>
Date: Wed, 30 Jan 2013 15:37:17 -0600

On Wed, Jan 30, 2013 at 3:31 PM, Adrien W. de Croy <[email-masked]> wrote:
> difference between a request that a client thinks it is sending to a proxy,
> vs a request the client thinks it is sending to a server.
>
> [...]
> In fact for authentication, I would extend it to allow for the definition of
> the target of the auth.  If you have a request going through a chain, and
> several links require auth from the client, there's currently no way to do
> it safely.

There are separate headers for authentication to proxies.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 30 Jan 2013 22:48:51 +0100

> Indeed. +1 on all the above.

+1 for me too. Looking up the header and concatenating it with the URI
to permit string matching is quite inefficient and we already have to
do it due to end-user demand.

Willy

---

From: Ted Hardie <[email-masked]>
Date: Wed, 30 Jan 2013 13:51:47 -0800

> vs a request the client thinks it is sending to a server.

So, I remember vividly the meeting at which the Host: header
discussion occurred, and I have heard John Klensin rant about this
many times since (he was the APPs AD at the time), so my context on
this is probably a bit odd.  At the time, we added the host header to
help stave off the consumption of independent IP addresses for web
sites that were being served off the same servers and physical
infrastructure.  Pretty much everyone at the time thought the *right*
idea was to move to full URLs.  We were reluctant to do so because of
installed base and, because this could be a "breaking change", the
consequences of revising the version number.  The questions about the
HTTP WG minutes on the topic (kicked off by Harald Alvestrand) start
here:  http://www.hpl.hp.com/personal/ange/archives/archives-96/http-wg-archive/0687.html
 and they are quite amusing to read now.

We had no idea how early we were in the popularity curve of HTTP or
how dominant it would become, but it was clear even then that the
protocol would be very, very common on the network.  In retrospect, it
is clear that we shouldn't have looked at the current installed
base--we should have looked at what we expected eventual use would be.
 That makes "the earlier the better" clear.

For HTTP 2.0, where we can make non-backward compatible changes, I
personally think the right thing to do is to drop the Host: header
(that version shift is what we were waiting for 17 years ago, after
all).  If there are things folks are getting from side-effects of the
Host header (e.g. proxy targeting), we put them into the bin of
potential requirements for HTTP 2.0 *and create mechanisms to meet
those needs*.

I think Adrien's proposal for extensions to the host header makes
clear that the need isn't perfectly met by the host header in any
case, so mapping out the real aim and meeting that seems like the best
notion to me.

Just my two cents,

Ted

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Jan 2013 22:32:47 +0000

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <CA+9kkMBDT9129r=[email-masked]>, Ted Hardie writes:

>In retrospect, it

A mistake this WG seems hell-bent on repeating with HTTP2 in my view...

---

From: Roberto Peon <[email-masked]>
Date: Wed, 30 Jan 2013 14:48:21 -0800

Dropping the host header will inflate the size of bytes on the wire, to the
detriment of latency.

I haven't yet heard of a real performance advantage for dropping it. Is
there one?

-=R

On Wed, Jan 30, 2013 at 2:32 PM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <CA+9kkMBDT9129r=
> [email-masked]>, Ted Hardie writes:
>
> >In retrospect, it

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Jan 2013 22:55:17 +0000

>Dropping the host header will inflate the size of bytes on the wire, to the

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

High-performance implementations would not have to text-process the entire
header to find the fqdn they use for routing decisions.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 30 Jan 2013 23:01:57 +0000

If we're going to a binary protocol, we should be looking at every 
opportunity to get rid of requirements to parse strings.

IMO this means sending each part of a URI separately in its own field.

Adrien

------ Original Message ------
From: "Poul-Henning Kamp" <[email-masked]>
To: "Roberto Peon" <[email-masked]>
Cc: "Ted Hardie" <[email-masked]>; "Adrien W. de Croy" 
<[email-masked]>; "Eliezer Croitoru" <[email-masked]>; 
"[email-masked]" <[email-masked]>; "John C Klensin" 
<[email-masked]>
Sent: 31/01/2013 11:55:17 a.m.
Subject: Re: Do we kill the "Host:" header in HTTP/2 ?
><[email-masked]>, 
>Roberto Peon writes:
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 30 Jan 2013 15:04:24 -0800

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 <[email-masked]>wrote:

> [email-masked]>,
> Roberto Peon writes:
>

---

From: James M Snell <[email-masked]>
Date: Wed, 30 Jan 2013 15:12:25 -0800

> I thought we hadn't decided how things would be encoded yet, so how can
As far as Delta encoding is concerned, yes, because it means the host would
have to be specified in every request rather than be stored in the context.

Yes, we have not yet decided on the specific encoding yet so you're both
correct.

> Which looks like a one byte saving to me ?
I think we can all agree that the host information needs to be there
somewhere. It's just a matter of deciding exactly where it is the most
beneficial. Host is just one of the headers that middle boxes can use to
direct requests, and while it may be perfectly fine to remove the host
header, removing it from the header block does not guarantee that
additional text-processing won't be necessary. (Note, for instance, that if
we just rely on host in the request URI, a particular middle box that
routes just off the host name and not the url will still need to do text
processing).

I'm personally no where near convinced that there's a need to remove Host.
I see it as being quite useful in many scenarios and we have to keep it
around for backwards compatibility with 1.1 impls anyway.

- James

---

From: Larry Masinter <[email-masked]>
Date: Wed, 30 Jan 2013 15:17:00 -0800

> header to find the fqdn they use for routing decisions.

One of the design goals of the "host:" header was that most sites could ignore the host header except to insure there is one.
The impact was only if those high-performance implementations were using single IP address for multiple host names.

(Which would kind of be antithetical to a high-performance deployment, no?)

Larry
--
http://larry.masinter.net

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Jan 2013 23:23:12 +0000

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <[email-masked]>, Roberto Peon writes:

>text-process the entire headers to find the fqdn. 

(In HTTP/1.1 you need to find the Host: header, it can be anywere,
any number of times, including 0 times.)

>previous request without any parsing at all.

That's slightly different question IMO.

The question I'm asking, is this:

	Are we going to have both a "URI" and a "Host:" field ?

	The issue here is: What if neither or both have FQDN's,
	what if they disagree and all that jazz...

You question is more like:

	Are we going to transmit URI and FQDN separately ?

to which my counter question is:  Which "FQDN" would that be, the
one from the absolute URI ?  Or the one from the Host: header ?

It seems to me that the sanest decision is:  "All URIs MUST
be absolute, but we might preparse them and transmit the
fqdn separately for reasons of effciency, and we have no
dedicated Host: header in HTTP/2.0"

---

From: Nico Williams <[email-masked]>
Date: Wed, 30 Jan 2013 17:26:37 -0600

So make the HTTP/2.0 equivalent of Request-Line have the URI scheme,
host name FQDN, and URI local part all contiguous, trivially
separated/parsed (e.g., with a length field for each, possibly a
varint length).

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Jan 2013 23:28:13 +0000

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <[email-masked]>, Larry Masinter writes:

>The impact was only if those high-performance implementations were using
>single IP address for multiple host names.
>

Uhm, have you read this ?

	http://www.ripe.net/ripe/docs/ripe-553

Even very high performance sites have multiple FQDNs per IP number these
days and the Host: header is often more important than the URI, because
high-performance load-balancers route HTTP only using that.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Jan 2013 23:29:18 +0000

>separated/parsed (e.g., with a length field for each, possibly a

Works for me...

---

From: Patrick McManus <[email-masked]>
Date: Thu, 31 Jan 2013 08:31:54 +0900

On Thu, Jan 31, 2013 at 8:04 AM, Roberto Peon <[email-masked]> wrote:

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

> previous request without any parsing at all.
and we can apply a requirement to order things :scheme, :host, :uri in
order to facilitate streaming ..

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Jan 2013 23:36:45 +0000

>order to facilitate streaming ..

And then we're back to my underlying question:

Isn't that the sort of thing we should settle before people spend a lot of
time on simulating compression and encoding schemes, as this will clearly
have significant impact on the results of those experiments ?

---

From: Roberto Peon <[email-masked]>
Date: Wed, 30 Jan 2013 15:51:06 -0800

Yup. It is pretty important :)
-=R

On Wed, Jan 30, 2013 at 3:36 PM, Poul-Henning Kamp <[email-masked]>wrote:

> [email-masked]>,
> Patrick McManus writes:
>

---

From: RUELLAN Herve <[email-masked]>
Date: Thu, 31 Jan 2013 00:05:39 +0000

I would think we should do both in parallel: yes this sort of thing will have an impact on the results of those experiments, but this should be mitigated by fine-tuning the code used in the experiment.
On the other side, having some early results from the experiments may help us having a better view of what is the tradeoff we have to make.

Hervé.
________________________________________
From: Poul-Henning Kamp [[email-masked]]
Sent: Thursday, January 31, 2013 00:36
To: Patrick McManus
Cc: Roberto Peon; Ted Hardie; Adrien W. de Croy; Eliezer Croitoru; [email-masked]; John C Klensin
Subject: Re: Do we kill the "Host:" header in HTTP/2 ?

---

From: RUELLAN Herve <[email-masked]>
Date: Thu, 31 Jan 2013 00:08:33 +0000

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 [[email-masked]]
Sent: Thursday, January 31, 2013 00:04
To: Poul-Henning Kamp
Cc: Ted Hardie; Adrien W. de Croy; Eliezer Croitoru; [email-masked]; 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 <[email-masked]<mailto:[email-masked]>> 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 ?
<[email-masked]</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 >

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 31 Jan 2013 01:18:35 +0100

> have significant impact on the results of those experiments ?

Both are done more or less in parallel, we should not have a religion
about this. If someone comes up with a smart new way to very efficiently
transport such information that is different from what was agreed the
day before, well, let's study the solution before saying "nah, we agreed
on a different transport method".

I know that my mind is mixed on the subject. As an intermediary implementer
I need to find Host very quickly, and having it with the scheme and URI
would be very convenient. But at the same time, I noticed that it might
or might not be the best solution for compression. Lately when I came up
with an idea of a "base" url, it was something different again and I had
no trouble with that. So let's declare *preference* and find what is best
in the end, then tune it to best fit declared preferences if still
applicable.

Regards,
Willy

---

From: Roberto Peon <[email-masked]>
Date: Wed, 30 Jan 2013 16:45:33 -0800

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
<[email-masked]>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 [[email-masked]]
> *Sent:* Thursday, January 31, 2013 00:04
> *To:* Poul-Henning Kamp
> *Cc:* Ted Hardie; Adrien W. de Croy; Eliezer Croitoru; [email-masked];
> John C Klensin
>
> *Subject:* Re: Do we kill the "Host:" header in HTTP/2 ?
>
>  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
>
>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 31 Jan 2013 01:23:04 +0000

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" <[email-masked]>
To: "RUELLAN Herve" <[email-masked]>
Cc: "Poul-Henning Kamp" <[email-masked]>; "Ted Hardie" 
<[email-masked]>; "Adrien W. de Croy" <[email-masked]>; "Eliezer 
Croitoru" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "John C Klensin" <[email-masked]>
Sent: 31/01/2013 1:45:33 p.m.
Subject: Re: Do we kill the "Host:" header in HTTP/2 ?
>because it leaks no information that anyone wouldn't have already been 
>able to get earlier.
>
>-=R
>
>
><[email-masked]> wrote:
>>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é.
>>--------------------------------------------------------------------------------
>>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.
>>
>>prior URL, and it is extremely common for the scheme and the host to 
>>remain constant across a large number of queries.
>>
>>
>>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).
>>
>>changed, a simple single 'if' allows us to proceed with the fqdn of 
>>the previous request without any parsing at all.
>>
>>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 
>><[email-masked]> wrote:

---

From: Zhong Yu <[email-masked]>
Date: Wed, 30 Jan 2013 20:34:56 -0600

> * split querystring into individual tuples as well and put them in a

If you are talking about x-www-form-urlencoded query format, it is
very specific to HTML form submission. Not all server applications use
that format to construct queries. So it's inappropriate for HTTP to
pick it as *the* query format.

> * deprecate %encoding (no longer needed since nothing is parsed)

While %encoding sucks, many applications treat URIs as opaque char
sequences instead of structured data, so some escaping is unavoidable.

Zhong Yu

---

From: RUELLAN Herve <[email-masked]>
Date: Thu, 31 Jan 2013 03:58:48 +0000

I agree that we should go further. Fully removing prefix-matching has a strong impact on compaction.

Hervé.
________________________________
From: Adrien W. de Croy [[email-masked]]
Sent: Thursday, January 31, 2013 02:23
To: Roberto Peon; RUELLAN Herve
Cc: Poul-Henning Kamp; Ted Hardie; Eliezer Croitoru; [email-masked]; John C Klensin
Subject: 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" <[email-masked]<mailto:[email-masked]>>
To: "RUELLAN Herve" <[email-masked]<mailto:[email-masked]>>
Cc: "Poul-Henning Kamp" <[email-masked]<mailto:[email-masked]>>; "Adrien W. de Croy" <[email-masked]<mailto:[email-masked]>>; "[email-masked]" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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 [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, January 31, 2013 00:04
To: Poul-Henning Kamp
Cc: Ted Hardie; Adrien W. de Croy; Eliezer Croitoru; [email-masked]<mailto:[email-masked]>; John C Klensin

---

From: Eliezer Croitoru <[email-masked]>
Date: Thu, 31 Jan 2013 14:22:10 +0200

> high-performance load-balancers route HTTP only using that.
The only reason they use the Host: header is since it's there.
It can be simply measured if needed.

-- 
Eliezer Croitoru

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 31 Jan 2013 05:15:23 -0800

> and they are quite amusing to read now.

http://www.hpl.hp.com/personal/ange/archives/archives-96/http-wg-archive/0726.html

> That makes "the earlier the better" clear.

I think your memory is a bit hazy there ... HTTP passed all
application protocols other than email in 1995, and by that
time (Mar 1996) was roughly double email traffic, IIRC (this was
before email-based spam became common).  That's why the WG
meeting contained a lot of people who had nothing to do
with developing the Web protocols---there was panic in the air.

I find it amusing that you think we could have proceeded in any
other way without relegating the IETF work to the garbage bin.

> case, so mapping out the real aim and meeting that seems like the best

Oddly enough, waka separates the scheme+host routing information from
the rest of the URI because that works better with multi-argument
methods and message-based encryption. *shrug*

....Roy

---

From: Ted Hardie <[email-masked]>
Date: Thu, 31 Jan 2013 08:04:21 -0800

On Thu, Jan 31, 2013 at 5:15 AM, Roy T. Fielding about this

> with developing the Web protocols---there was panic in the air.

I think we can both agree it only got more popular from there.  It may
well have surpassed email by that discussion, but the hockey stick had
a lot of run to go.

> other way without relegating the IETF work to the garbage bin.

It would have taken agreement from a lot of people, but the web
community of the time could have decided then to rev the major
protocol version for that change.  That suggestion was made.  The IETF
could not have mandated that.  The IETF *never* gets to dictate
protocol changes--it didn't have police then and it doesn't now, but
saying that the buy-in for that change didn't happen doesn't equate to
saying it could not.

regards,

Ted

---

From: James M Snell <[email-masked]>
Date: Thu, 31 Jan 2013 23:09:42 -0800

One proposal on this particular topic...

We can combine the :scheme, :method, :host and :path header fields into a
single :req Header with a compact binary encoding and require that this
single header always appear first in request header blocks.

+------------------------------+
|S|len(method)|method|len(host)|
+-+-------+----+---------+-----+
|   host  | len(path) |  path  |
+------------------------------+

S = Single bit, when set, scheme = https, when not set, scheme = http
len(method) = 7 bit length of method name
method = name of method
len(host) = uvarint(host)
host = host
len(path) = uvarint(path)
path = path

Examples:

GET request for http://example.net/foo would be:

  [03,G,E,T,0B,e,x,a,m,p,l,e,.,c,o,m,04,/,f,o,o]

POST request for https://example.net/foo would be:

  [84,P,O,S,T,0B,e,x,a,m,p,l,e,.,c,o,m,04,/,f,o,o]

Unregistered method 'FOO' request for https://example.net/foo would be:

  [83,F,O,O,0B,e,x,a,m,p,l,e,.,c,o,m,04,/,f,o,o]

If the client chooses not to send a host (because it's not needed or
whatnot) they simply set len(host) to 0...

  [03,G,E,T,00,04,/,f,o,o]

If we do end up going with delta encoding for compression, we can require
that the :req Header always be passed using the eref operation (ephemeral
reference, meaning that the header is never stored in the compression
state). No huffman-coding would be applied to the header, making it very
quick and cheap to process.

Thoughts?

- James