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