httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@avron.ICS.UCI.EDU>
Subject Re: more Keep-Alive - possible problem
Date Fri, 09 Feb 1996 22:42:06 GMT
> Yuck yuck. It just gets worse.
> I've just checked netscape-2, and it sends
> Proxy-Conenction: Keep-Alive
> when it thinks it's talking to a proxy.

Yeah -- I was about ready to strangle Lou when he told me about that
last month.  The whole purpose for having a single Connection header
is so that proxies can remove it without knowing what the options mean.
Netscape will have to change their implementation, since it doesn't
even solve the problem.

> Having two different Connection headers seems really broken.
> The client is really not in a position to choose which to use.
> Presumably it uses Proxy-Connection: if it is configured to connect to
> a `proxy'. But what if the proxy is in fact the origin server?
> This implies that the header semantics must change depending on whether
> a server ( receives
> or /path in the request.
> Thus the first form cannot be allowed for non-proxy requests (as the
> HTTP/1.1 draft would imply).
> But what's worse is the other case, when netscape thinks its talking to
> the origin server, and hence uses a Connection: header, but in fact
> this server is a gateway to another. CERN and my proxy module can
> both work in this mode; a local request for /mirror/other/fobar
> would be sent of as a request to with all the
> incoming headers. This will break if the remote server supports
> keep-alives.

Yep, it is a real mess now.  The compromise is to have

    Connection: keep-alive

sent in an origin server request, and

    Connection: proxy
    Proxy: <hostname/IP>:port

when making a proxy request.  Although this leaves gateways out, they
are considered less of an issue because both the gateway and origin server
are owned by the same people and thus can be consistently updated.

>>No, it is incorrect -- one of the requirements placed on NCSA and Spyglass's
>>implementations is that the Connection: Keep-Alive also guarantees a
>>correct content length.  If more data arrives, it should not be displayed
>>because the user needs to know that something is wrong with the server.
> Where is this behaviour documented?

In the HTTP/1.1 draft (hopefully).


View raw message