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