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

#303: Generic semantics for the 400 status code (also #302)

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 17 Jul 2011 10:54:39 +1000
Message-Id: <F0C6395C-9555-49AB-BEE9-055B41DC0160@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
On 15/07/2011, at 10:53 PM, 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).
> """

This was logged as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/303>.


> * Why is the "If the client is sending data..." section in p2 8.4? Seems like this belongs in p1...

This is now #302 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/302> (editorial)



--
Mark Nottingham   http://www.mnot.net/
Received on Sunday, 17 July 2011 00:55:06 GMT

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