Re: [Lynx-dev] back to the question on lynx vs wiki

[Thomas Dickey]

On Fri, May 18, 2007 at 07:36:50AM -0400, Virden, Larry W. wrote:
> As you may remember, I reports a strange interaction I am experiencing
> on http://wiki.tcl.tk/ . Here's the latest info on the situation.
> If anyone has any suggestions, we'd love to hear them.

The problem went away temporarily, and is back again.

> 'HTTP/1.1 200 OK
> Date: Thu, 17 May 2007 22:57:38 GMT
> Server: Wub 2.0
> etag: "tid0x4a801bb0.1179442658461135"
> cache-control: public, max-age=0, must-revalidate
> content-length: 7416
> content-type: text/html; charset=utf-8
> last-modified: Tue, 15 May 2007 20:47:00 GMT
> Connection: close

The behavior for this doesn't seem to be _precisely_ specified in RFC 2616.

Arguably since the content length is given, a client can decide to ignore
the connection until the server gets around to closing it.  Other servers
do this immediately after sending the response (even when they send the
content length).  But the RFC doesn't say anything more definite than this
(in 8.1.2.1):

        An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
        maintain a persistent connection unless a Connection header including
        the connection-token "close" was sent in the request.  If the server
        chooses to close the connection immediately after sending the response,
        it SHOULD send a Connection header including the connection-token
        close.

...

        If either the client or the server sends the close token in the
        Connection header, that request becomes the last one for the
        connection.

There are some other vague statements, but none that guarantee "prompt"
closure of the connection - just that the server has to do it.

Left unanswered is whether it is permissable to send the Connection
header without closing the connection "immediately".
 
> Do you think one of your Lynx contacts could cast an eye over this and
> give some opinion about what might be causing Lynx problems?  I'm sure
> that if it's a back-compatibility problem, then the problem is stemming
> from my lack of adherence to standards, but I don't know which part of
> rfc2616 I'm failing.  I'd certainly like to keep /1.0 browsers happy,
> or at least semi-functional, for as long as they exist.

The server isn't closing the connection until 20 seconds after sending
the reply.  lynx and w3m are single-threaded, and are waiting for the
connection to close.

If this were a common problem with servers, one could modify lynx to detect
that the connection is abandoned in this special case (close-token with
content-length), and do some type of polling to flush out stale connections.

But it would be nice to know if there's a good technical
reason why the tcl server has to do this - unlike the other servers.

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net