RE: Proxy-Connection header definition?

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.
>

Received on Tuesday, 26 January 1999 22:09:59 UTC