W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: HTTbis spec size, was: Rechartering HTTPbis

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Sat, 28 Jan 2012 14:09:36 +0000
To: Willy Tarreau <w@1wt.eu>
cc: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <3581.1327759776@critter.freebsd.dk>
In message <20120128134010.GK22945@1wt.eu>, Willy Tarreau writes:
>On Sat, Jan 28, 2012 at 10:28:38AM +0000, Poul-Henning Kamp wrote:

>> Which 3 tokens of this HTTP request is transport information:
>> 
>> 	>>> GET / HTTP/1.1
>> 	>>> Host: www.example.com
>> 	>>> User-Agent: fetch libfetch/2.0
>> 	>>> Connection: close
>> 
>> Answer: "HTTP/1.1", "www.example.com" and "close".
>> 
>> Everything else is content, including "GET".
>
>It's not that black and white nowadays. Many sites "route" by URI,
>meaning the "/" is also part of the transport to some extent (eg:
>route to static servers rather than application servers).

They're welcome to do so in the future as well, but it should be
clearer for everybody involved that they are rounting based on
the request content then.

The reason I made the URI part of object-metadata, is that it
may need security/privacy/integrity protection.

>     4- payload         -> path, content-types, etc...
>     3- session         -> cookies, user info, auth
>     2- scrambling      -> TLS or whatever comes next
>     1- transport       -> MUX, pipelining, keep-alive

I generally agree, but I'm not sure if 1&2 are above/below or side-by-side.

That question really boils down to if the Host: header is privacy
protected or not.  This becomes a particularly intricate dance once
anonymising proxies are involved.

If Host: should have privacy, then HTTPS, as we know it, where the
entire TCP connection is encrypted, is the answer.

If Host: should not have privacy, in order to allow traffic directors,
load-balancers and similar to dispatch secure traffic without terminating
the crypto-session, then a payload-only SSL scheme would be preferable.

I'm in no position to make a call on this.

-- 
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 Saturday, 28 January 2012 14:10:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:53 GMT