protocol support for intercepting proxies

Hi all

I guess mentioning "intercepting proxies" is probably akin to swearing 
on this list, as they break many aspects of the spec, (and TCP).

However, in this customer-wants-customer-gets world of ours, many proxy 
vendors are commercially forced to provide implementations.

It is very appealing for system administrators to install an 
intercepting proxy, as it "solves" the issue of client browser 
configuration.  Sure, there are many other methods of auto-proxy 
configuration, but these all rely on ancillary systems and extra 
sys-admin (and sometimes customer) knowledge (i.e. DHCP option 242, 
and/or DNS WPAD lookup).

Vendors who implement intercepting proxies do so without much (if any) 
support from the spec, and so there are issues encountered  which end up 
being solved by trial and error or best guess or in some cases are not 
even solvable (not reliably or properly anyway).

For instance the issue when a proxy intercepts connections then wishes 
to force the UA to authenticate to the proxy.

This is a really common scenario.

Since the UA doesn't believe it is talking to a proxy, it will only 
process WWW-Authenticate headers, not Proxy-Authenticate ones, and sends 
Connection headers instead of Proxy-Connection.  Often a UA will behave 
quite differently if it believes it is talking to a server than a proxy 
(for instance handling of POST requests in IE).

Given that the problem is not going to go away because people are not 
going to want to stop using intercepting proxies, wouldn't it be better 
if there was some proper protocol support for the concept?

UAs at the moment don't generally know if their connections are being 
intercepted.  If they knew, then they could;

* let the user know connections were being intercepted
    - ameliorates issues relating to privacy
    - helps users decipher errors better (i.e. upstream connection failure)
    - leads towards possible user-control over whether their traffic may 
be intercepted or not
* cooperate better with the proxy.
    - move to a proxy-oriented protocol operation (can fix many issues, 
such as auth)
    - deal with errors differently

I believe that this could be achieved with either a status code, or a 
header, where an intercepting proxy could signal to a client that it 
intercepted the connection.  The proxy could even intercept connections 
and enforce the UAs to use a proxy method, provide a proxy URI in the 
response that the UA must use.   This is another case where 305 
would/could have been useful.  Another option would be a warning code to 
indicate the connection had been intercepted.  I believe system 
administrators would wish to be able to configure how to deal with the 
case from a number of options including

1. Allow the clients to operate through the intercepting proxy
    - with notification
    - silently
2. Force the clients to re-connect to the proxy and issue requests with 
proxy semantics.

Option 1 would only require a header field (perhaps Warning), option 2 
would require a Location header to be used, and most likely a status code.

Adrien

Received on Sunday, 17 June 2007 22:23:28 UTC