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 archive: - 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. Anselm.BairdSmith@inria.fr - http://www.inria.fr/koala/abaird.htmlReceived on Tuesday, 10 October 1995 09:47:16 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:56 UTC