RE: Proxy-Connection header definition?
Yaron Goland (yarong@microsoft.com)
Tue, 26 Jan 1999 20:59:49 -0800
Sorry, a slip on the term authenticate. A persistent connection is needed
for some of our authentication algorithms to work properly.
As for the problems with the header, yes I am aware of the issues. I wasn't
actually around when the feature was put in so I'm not sure what the
arguments were that lead us to adopt it. I suspect they went something like
"Netscape is doing it so we have to do it."
Yaron
> -----Original Message-----
> From: Marc Slemko [mailto:marcs@znep.com]
> Sent: Tuesday, January 26, 1999 12:39 PM
> To: Yaron Goland
> Cc: http-wg@cuckoo.hpl.hp.com
> Subject: RE: Proxy-Connection header definition?
>
>
> On Tue, 26 Jan 1999, Yaron Goland wrote:
>
> > I too am unaware of a formal definition but we implement it
> in IE 4.0 and IE
> > 5.0. I also believe we implement it in IE 3.0 but am too
> lazy to go back and
> > check. It has worked out quite well for us allowing us to
> authenticate
>
> Authenticate?
>
> > against HTTP/1.0 proxies without worrying about breaking
> against 1.0 proxies
> > that don't support the mechanism and thus always pass the header on.
>
> No. The whole problem is that it doesn't work with proxies that don't
> understand it if you have anything more complex than client to
> proxy to origin server.
>
> From what I know, Netscape wanted a quick hack to let them do
> persistent connections to proxy servers without having to have all
> clients and proxies and servers support it. Unfortunately, their
> quick hack was too hacky and quickly falls apart when you have chains
> of proxies.
>
> C(a) -> P(b) -> P(c) -> O(d)
>
> C is client, P is proxy, O is origin server.
>
> a sends a Proxy-Connection to b. b doesn't understand the
> Proxy-Connection
> header, so it passes it on. c understands it, so it tries to do a
> persistent connection with b. Things break.
>
> What the Proxy-Connection header has done is require that every
> proxy which can pass requests to an "upstream" proxy of some type
> know about it or be "broken". In reality, it is the concept of the
> Proxy-Connection header that is broken, but given that
> clients implement
> it and other proxies implement it, the only thing this poor little
> standards conforming proxy can do is deal with it as well.
>
> It doesn't, of course, have to do anything other than drop it from
> forwarded requests, but that still involves dealing with it.
>
> In fact, you even run into this problem sometimes in situations
> where the proxy thinks it is talking directly to the origin server,
> due to hacks like broken "transparent proxies" (which, of course, by
> definition are broken), broken "reverse proxies" that think they are
> still proxies (eg. www.novell.com used to be behind one), etc.
> These cases are different though, since it is much more arguable
> that the "normal" proxy isn't the thing that should be fixed.
>