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 22:28:04 +0200
To: Adrien de Croy <adrien@qbik.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1248380884.14420.98.camel@localhost.localdomain>
fre 2009-07-24 klockan 07:44 +1200 skrev Adrien de Croy:

> In the context of the application I was considering a "please try again 
> later" type response for, I wouldn't consider this to be an error 
> condition.  Just a server policy for rate-limiting requests.

My reasoning is that it's an error condition which prevented the server
from fulfilling the request at the moment.

But seriously, a new 4xx code with Retry-After could also be issued for
this. It's a borderline case.

> again, in the case I was considering, it's more a server policy - 
> unwilling to comply, but happy to do so in X seconds if the client retries.

And I see that as a 5xx.. server could/would not complete the request
for some reason. Nothing wrong with the request, and no special action
needed to be done by the client other than try again at a later time
when the condition has ceased.

> I've always assumed HTTP inherited its classes of error codes from SMTP, 
> but the 4xx series doesn't really fit that.  E.g SMTP uses 421 in this case.

HTTP does not use the same classes as SMTP.

In HTTP 4xx errors is permanent and the client SHOULD NOT retry the same
request (server fine, request not good) where 5xx errors quite often are
not (request probably good, but could not be processed for some
reason). 

SMTP is kind of the opposite, with 4xy being transient/temporary and 5xy
being permanent.

SMTP: 421 Service Unavailable, ....
HTTP: 503 Service Unavailable

But it's not a clear cut distinction in HTTP to be honest. 5xx is a bit
of a mixed bag and there is errors which don't fully fit either category
or which fits both..

> > If any such requirement is to be added it should not be a SHOULD
> > requirement, at most a "MAY retry" requirement.
>    
> sure, but rate limiting requests wouldn't work if the client doesn't retry.

And clients/users won't hang around for hours if Retry-After says they
should..

> I think you're right, when I tested once before I found it was ignored.
> 
> So it's a chicken and egg situation.  Proxies/servers can't use it until 
> clients support it.  Clients don't have an incentive to use it until 
> some servers use it.

What we can do is to clarify the intended use.

> exactly - I consider retrying qualifies as some further action :)

And I don't. By actions I consider things which actually changes
something about the request.

> The server could send back a 302 with a Location header specifying the 
> original requested URI.  Some browsers will re-request (ignoring 
> Retry-After from what I've seen).  Some complain about a request loop.

No, that does not indicate the intended semantics I think. Plus will
fail badly for those not caring about Retry-After having some meaning..

> IE7 for instance will make over 3500 requests/sec to our proxy if we do 
> this in policy.  A good way to fill up HD. To rate limit in the end we 
> had to delay the response from the proxy.

Nice one.

Good thing FF warns users so these problems actually is detected
somewhere other than full logs...

Regards
Henrik
Received on Thursday, 23 July 2009 20:28:47 GMT

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