Re: p1-message-07 S 7.1.4

Henrik Nordstrom wrote:
> 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?
>
>   
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.

> 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.
>   
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.

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.

>> 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.
>   
sure, but rate limiting requests wouldn't work if the client doesn't retry.

>> 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.
>
>   
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.

>> 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.
>   
exactly - I consider retrying qualifies as some further action :)

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.

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.

Regards

Adrien

> Regards
> Henrik
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Thursday, 23 July 2009 19:41:33 UTC