Re: keep alive

John Franks writes:
 > According to Beth Frank:
 > The NCSA reference you give says:
 >    "Shortly after implementing the keepalive feature in HTTPd, a similar
 >    mechanism known as session extension, was proposed by the IETF for
 >    HTTP1.1. The mechanics are similar to our current implementation, but
 >    there are differences. We will most likely be modifying our keepalive
 >    implementation to be compatible with the session extension proposal
 >    during this beta. This should, for the most part, be transparent to
 >    the administration of HTTPd."
 > This together with the comment of Anselm above makes it sound as if your
 > implementation is not compatible with that spec. Is there any way that
 > browser or server writers can be compatible with you?  Is there any
 > description anywhere of what you have implemented?  If you interoperate
 > with Spyglass and Netscape how was this achieved without any specification?

I am afraid I haven't made my mail precise enough. I sent yesterday (in
a private mail) the differences between Netscape keep-alive and Mosaic
keep-alive, which are both different from the draft mentionned in WG

- Netscape: sends 'connection: Keep-Alive' and requires that the server
sends back a 'connection: Keep-Alive'
- Mosaic: sends 'connection: Keep-Alive' and requires that the server
sends back a 'Keep-Alive: <any value>'
- the draft says: browser should send 'connection: maintain' and the server
reply with 'connection: maintain'.

If some of the above is incorrect, let me know. 

In the mean time, I think I have found a bug in Mosaic implementation
of keep alive (which I have "fixed" - in a real hacky way). I still
have a problem with Netscape (2.0b1), when the reply to the request
does not have any entity body (such as an IMS reply, with status
NOT_MODIFIED), and am still looking for doc on how to cope with this
(if this is not a bug, but as long as I don't have the sources, I
can't tell).

Anselm. -

Received on Tuesday, 10 October 1995 09:47:16 UTC