Re: Header Size? Was: Our Schedule

On May 31, 2014, at 2:52 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

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

Indeed. I do like the idea of separating routing from other headers, in particular because it becomes trivial for a proxy implementation to inspect and append additional routing information. 

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

It still has to be limited to per-frame compression, because shared compression state means that a proxy must process and convert all metadata. 

As a server and proxy implementer I would prefer modest gains in packet size that didn’t sacrifice throughput already achievable in http 1.1, and IMO the static tables do exactly that. I can certainly appreciate that those implementing clients don’t agree with this perspective, and would like more.
 
> 
> 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.
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Sunday, 1 June 2014 18:29:20 UTC