On Wednesday 27 November 2002 14.12, Robert Collins wrote:
> That should not happen. If two proxies are in a chain, the one
> closest to the client can only sanely add the session
> authentication header flag when it sees a server auth request if
> a) that request was not through an upstream, and it has discretion
> on future requests.
> b) the upstream proxy also added the header.
The problems arise if the situation is reversed. The upstream proxy
supports the connection pinning extension, but the downstream proxy
does not.
Then the upstream proxy will signal that connection pinning is
supported, but the downstream proxy will not know about this and
won't do any connection pinning.
As the headers is not protected by Connection headers the downstream
proxy has no clue that it needs to remove the HTTP header signalling
that connection pinning is supported, so this will get forwarded to
the browser, fooling the browser into thinking connection pinning is
supported.
To summarise: The proposed scheme is overly complex and not doing what
it is supposed to be doing.
Again, the same kind of errors, not accounting for the end-to-end vs
hop-by-hop properties of HTTP.
Regards
Henrik
Received on Wed Nov 27 2002 - 07:55:32 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:11:36 MST