W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

408 Timeout details

From: Robert Brewer <fumanchu@aminus.org>
Date: Wed, 27 May 2009 13:46:13 -0700
Message-ID: <F1962646D3B64642B7C9A06068EE1E6418B3E5@ex10.hostedexchange.local>
To: "HTTP Working Group" <ietf-http-wg@w3.org>
Hi all,

A while ago, I attempted to add the ability to send 408 Request Timeout
to CherryPy (an HTTP server written in Python). It had some
problems--people were getting "random" 408 responses. I traced the
problem down to our error trap in the server, which was sending 408 on
any socket.timeout, as long as the response headers for the current
request had not yet been sent. If they had, we just dropped the conn.

As I described in http://www.cherrypy.org/ticket/853#change_8, the above
approach didn't quite work, because in many cases the server side of the
socket would timeout while the client was busy processing the previous
response, even though the client's intent was to close the conn at the
end of the conversation. In that case, many clients would receive the
new 408 response in the same read(), and be confused. Therefore, I
changed CherryPy to only send 408 either before any initial request, or
during a request, but never between a response and the next request.
This fix seems to solve all the problems.

But I'm left wondering: what is the purpose of 408? Is the intent that
it could be sent at any time? Of the 3 options: before client's first
request, during client request (and server response), between client
requests...to which is 408 intended to apply? The RFC somewhat
ambiguously says, "The client did not produce a request within the time
that the server was prepared to wait." I find myself interpreting that
in more than one way...


Robert Brewer
fumanchu@aminus.org
Received on Wednesday, 27 May 2009 20:47:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:03 GMT