[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Dickey
Subject: Re: [Lynx-dev] back to the question on lynx vs wiki
Date: Mon, 21 May 2007 20:14:28 -0400
User-agent: Mutt/1.5.13 (2006-08-11)

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 . 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

        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


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

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>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]