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