Re: Header Size? Was: Our Schedule

In message <332BBBAC-C4EE-4A62-85C3-10BBA389FD4A@redhat.com>, "Jason T. Greene"
 writes:

>IMO the only way to allow for a proxy to directly hand off requests as
>is would be per-frame compression, where the URL is easily located and
>matched. 

And this is why I think state-full compression of headers necessary
for routing HTTP is a terminally bad idea for HTTP/2.0, since it
causes state to materialize all over the place, state which increases
cost, decrease reliability and which is vulnerable to DoS'ing at
all the most sensitive choke-points.

My original suggestion was to have two parts to HTTP/2 transport
messages:

	[route headers]
	[payload]

Where the route headers would consist of:
	length of route headers
	length of payload
	Host:
	URL sans query part  (or possibly:  URL up to first '/')
	(X-)Forwarded-For:

(Trivial details to cater for multiplexing and "Chunked" style
incremental delivery left out for clarity).

Route headers are uncompressed, in order to make it possible to
route 1Tbit/sec HTTP traffic without holding an expensive state.

The payload consists of metadata and objects

Metadata is the rest of the HTTP headers, which are not needed for
transporting HTTP, but only play a role in semantic interpretation:
Content-Type, Content-Encoding etc. etc.

Metadata and object can be compressed or encrypted how ever you like.

The information leak of the Host: and first part of the URL are
insignificant relative to privacy:  If a site wants to
offer increased privacy, both can trivially be emptied of
information in the site-design.

Having the route header unencrypted also means that legally mandated
inspecting proxies can *avoid* inspecting privileged traffic for
instance between prison inmates, their lawyers and politicians,
by implementing a white-list.



-- 
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, 31 May 2014 19:53:15 UTC