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

RE: Header Size? Was: Our Schedule

From: <K.Morgan@iaea.org>
Date: Sun, 1 Jun 2014 00:10:42 +0000
To: <phk@phk.freebsd.dk>, <jgreene@redhat.com>
CC: <grmocg@gmail.com>, <gregw@intalio.com>, <ietf-http-wg@w3.org>
Message-ID: <0356EBBE092D394F9291DA01E8D28EC201186D8A93@sem002pd.sg.iaea.org>
Hi Poul-Henning-

I'm not very familiar with proxy design and constraints, but it sounds like a reasonable idea to me. From a performance point of view, it seems like a bad idea for proxies to constantly decompress (and possibly recompress) headers.

Could you achieve the same goal within the current spec by requiring the route headers to come first and uncompressed in the first HEADERS frame of a stream?

Are these headers you mentioned the only three proxies ever need to look at when forwarding requests?
>        Host:
>        URL sans query part  (or possibly:  URL up to first '/')
>        (X-)Forwarded-For:

What about forwarding responses back to the client? I imagine you would want to do a similar thing. Same headers?

-keith


On 31 May 2014 21:52, 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.

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.
This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
Received on Sunday, 1 June 2014 00:11:33 UTC

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