No Wait in HTTP
Posted by billburke on November 10, 2009
One thing the HTTP specification does not have is a “Server Timeout” response code. The 408 and 504 response codes are the only thing that comes close. The idea of a “Server Timeout” code is that the server received the request, but timed out internally trying to process the request. Another thing I think that is missing from HTTP is a way for the client to tell the server how long it is willing to wait for a request to be processed.
I’ve run into both of these scenarios with the REST-* Messaging specification when I have pulling client consumers. For the “Server Timeout” I decided upon 202, Accepted. It seems to fit as I can tell the client to try again at a specific URL. As for the client requesting a wait time? I invented a new request header: “X-RS-Wait”. Its value is the time in seconds that the client wants to wait for a request to be processed. Maybe there is a standard or drafted protocol I missed in my Google search?
Mike Amundsen said
Failed requests due to server issues needs to be reported as a 5xx response code. Why not use 503. This status code includes support for the
Retry-Afterheader that can indicate to the client when to re-try the request.Sending 2xx for a failed request is a bad idea.
Finally, I would suggest using an “Accept” header for the client wait time (
Accept-Wait). The Accept headers are “negotiated” between client and server and it might make sense to use this pattern for client timeout requirements. This would allow a server to return a 406 in cases where the client is asking for a timeout limit the server does not want to (or cannot) support.billburke said
Sounds interesting, but I can’t see the Accept-Wait negotiation ever being used. The server can just ignore the timeout request and return whenever it wants. Its just a suggestion by the client.
I picked 202, because it isn’t really a failed request. I guess combining 503 with retry-after is better. Then the server could calculate average message rate and use that as the retry time.
Mike Amundsen said
Not all Accept-* headers are MUST elements in HTTP; servers can decide to return something else instead. Accept-Encoding works this way. In fact many servers ignore the Accept: header quality values or the header completely when fulfilling requests for a client.
Hrish said
>>I decided upon 202, Accepted. It seems to fit as I can tell the client to try again at a specific URL
If the client posts the same data again for a timed out request, the result might not be what was intended. Some additional status exchange is required to handle these cases, IMO.