- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Thu, 23 Jul 2009 13:01:01 +0200
- To: Adrien de Croy <adrien@qbik.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
tor 2009-07-23 klockan 16:02 +1200 skrev Adrien de Croy: > Problem with 503 is RFC2616 S10.5 which states this is a Server Error. > Any client that just looks at the class of the response if it's not > 1xx, 2xx or 3xx will just see this as an error. How is the server not yet having completed it's internal processing so it can process the request in the expected manner not being an (expected) server error of temporary nature? For what it's worth the mechanism described here is unrelated to what made the server initiate this processing. It may have been an asyncronous POST, but may just as well have been any other action within or outside HTTP. The case here is that the server knows it should have a suitable representation for the response but at the time being it's unable to provide that representation due to a temporary condition. > Also S10.5.3 (503 Service Unavailable) doesn't even suggest that the > client SHOULD retry after the time specified in Retry-After (if it > exists) or some other time if it doesn't. Well, to me that's kind of implicit that the client is expected to retry the request after the indicated time if it's still interested by then, this from Retry-After indicating it's a temporary issue and the name of the header plus the talk forbidding the client from retrying before.. If any such requirement is to be added it should not be a SHOULD requirement, at most a "MAY retry" requirement. > So 503 I believe would be problematic for this case - I'll do some > testing with browsers and let you know what I find. I think you will find that none cares about Retry-After. > a) it's not a server or client error, but indicates to the browser it > must take further action There is no further action to be taken by the browser other than to wait patiently while the server sorts out whatever it's currently doing and then try the exact same request again if it is still interested in the result by then. Regards Henrik
Received on Thursday, 23 July 2009 11:01:44 UTC