httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@ast.cam.ac.uk (David Robinson)
Subject Re: more Keep-Alive - possible problem
Date Fri, 09 Feb 1996 13:28:00 GMT
>> This is what really annoys me about Keep-Alive, Host etc al;
>> there is no (provisional) standard these for features, and if there were
>> it would be called HTTP/1.1; yet browsers and servers are implementing
>> their understanding of these features without changing the protocol version
>> number.
>
>Yep, I could not convince people (particularly Spyglass) that the idea
>was to make an *experimental* implementation and not distribute it
>to the general public.  Instead, their marketing turned it into a feature
>because Netscape was out of the loop (i.e., they were not involved in the
>IETF at the time Keep-Alive was worked-out).  That also destroyed
>interoperability because now Keep-Alive cannot be trusted if it passes
>through a proxy.  So, we are stuck with inventing a new directive for
>the Connection header for a proxy keep-alive.

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.

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 (me.com) receives
http://me.com/path 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 http://other.com/fobar with all the
incoming headers. This will break if the remote server supports
keep-alives.

>> Netscape's behaviour is correct (even if it does highlight the problems
>> of Keep-Alive in 1.0); it should ignore the Content-Length header
>> if it conflicts with the amount of data sent by the server, as that
>> header cannot be considered reliable in HTTP/1.0.
>
>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?

 David.

Mime
View raw message