Re: Header Size? Was: Our Schedule

HPACK was designed to make re-indexing when proxying possible.
It would require some complexity (one has to keep a map of
client-side-index to server-side-index when sharing state between
client-side and server-side), but such is often the tradeoff for optimality.

Poul's proposal to put routing info at the front pre-supposes that all
proxies use the same information for routing.This is often not the case.
As per my experience, his list is incomplete. Routing often happens due to
method, user-agent, cookie, accept-encoding, etc., and sometimes some
random headers that the proxy is configured to examine. Basically, I can't
predict what these may be today, and thus forcing an ordering doesn't help
my proxy in most use-cases. In many cases, I'll want to capture the entire
block of headers before forwarding to servers which my proxy may protect.
Again, having some specific headers listed first doesn't help in that use
case.

Regardless, though, if one could identify this list then with something
like HPACK one simply refers to the index of those data at the start of the
header block.
This has been discussed before, I'll point out.
-=R


On Sat, May 31, 2014 at 5:10 PM, <K.Morgan@iaea.org> wrote:

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