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

Re: p1-message-07 S 7.1.4

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>
Message-Id: <1248346861.1806.18.camel@localhost.localdomain>
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 GMT

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