Re: Dealing with header injection through reverse proxies

> so that a server which supports this mechanism
> ends up behind a proxy which does not (and hence does not strip
> the headers).
>

If the problem can be reduced to the above then I think there are some http
features that are worth considering if you're willing to look at it as a
single hop requirement:

a] if the proxy->server link is h1 then the x-client-certificate name can
be included in the Connection header sent to the server (and the server can
enforce this property). Any naive proxy receiving that same combination
from a malicious client would remove the request-header of the same name
before forwarding it on to the server and then generate its own Connection
header.

b] if the proxy->server link is h2 then you can inject connection-specific
information into the stream with an extension frame type (and the server
can enforce this property). You don't need to negotiate it with SETTINGS
(which is nice, because that's a round trip.) and these frames are hop to
hop (proxies that don't understand a frame type MUST drop them).

Its not too hard to imagine a generalization of (b).. a
CONNECTION-SPECIFIC-HEADERS or somesuch that has strict hop-to-hop
semantics.

-P