Re: Generic semantics for the 400 status code

[Mark Nottingham <[e-mail]>]

Hi Willy,

On 15/07/2011, at 11:51 PM, Willy Tarreau wrote:

> Hi Mark,
> 
> On Fri, Jul 15, 2011 at 10:53:09PM +1000, Mark Nottingham wrote:
>> When people have error states that don't cleanly fit into an existing status code, they're often encouraged to use 400 or 500, depending on whether the client or server were at fault, as they're the most "generic" status codes.
>> 
>> 500's definition fits this:
>> 
>>> 8.5.1.  500 Internal Server Error
>>> 
>>>   The server encountered an unexpected condition which prevented it
>>>   from fulfilling the request.
>> 
>> However, 400 is much more specific:
>> 
>>> 8.4.1.  400 Bad Request
>>> 
>>>   The request could not be understood by the server due to malformed
>>>   syntax.  The client SHOULD NOT repeat the request without
>>>   modifications.
>> 
>> I think the 400 definition needs to be broadened, so that people don't invent their own status codes, or misuse existing ones.
>> 
>> E.g.,
>> 
>> """
>> The server can or will not process the request, due to a client error (e.g., malformed syntax).
>> """
>> 
>> Additionally, I think we should move the caution against retrying the request to the general 4xx section (8.4)*.
>> 
>> Background:
>>  http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/content/Synchronous_Faults-d1e1729.html#comment-213643851
>> 
>> Thoughts?
> 
> I have mixed opinions on this point.
> 
> On the one hand, yes we said a server could use 503 + Retry-After for rate
> shaping when it's overloaded. However in my opinion this is irrelevant to
> the client and it might return that to any request during the overload
> period. If the server is refusing to serve a client which is abusing, a 4xx
> seems more appropriate, since the cause is this specific client, but I don't
> see any existing one which fits the purpose.
> 
> I have a principle of always ensuring that a client cannot cause a server
> to emit 5xx codes if the server is working correctly. This is important
> for someone like me who spends a lot of time staring at gigs of logs,
> because when you spot a 5xx, it means something is going wrong with the
> server. The only exception I found to this was 501.
> 
> So my understanding has always been this :
>  - if the request is rejected because of the client, 4xx
>  - if the request is rejected regardless of the client, 5xx
> 
> The difference is important when intermediaries look at return codes.
> Some might want to reduce connection pools to the server when they see
> 5xx. Some will declare a server down or failing when they see 5xx.
> 
> Anyway, in the discussion at the link above, I'm not even sure the user
> needs to get a Retry-After : if the client is abusing its contract, then
> we don't necessarily want to see him reconnect ASAP when the abuse is
> over. Still it can make sense to define one 4xx for client abuse.


So, do you support the proposal I made?

Note that this doesn't preclude minting a new status code if that's the right thing to do.

--
Mark Nottingham   http://www.mnot.net/