W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Header Size? Was: Our Schedule

From: Jason Greene <jason.greene@redhat.com>
Date: Sun, 1 Jun 2014 13:28:45 -0500
Cc: "Jason T. Greene" <jgreene@redhat.com>, Roberto Peon <grmocg@gmail.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <7F1A1E55-55D4-427D-BB1B-67CE4424BE26@redhat.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC