W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1999

Re: HTTP/1.1 Error Responses

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Mon, 29 Mar 1999 18:32:52 -0800
To: Robert Inder <inder@etl.go.jp>
Cc: http-wg@hplb.hpl.hp.com
Message-Id: <9903291833.aa20324@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/384
>> Actually, it has.  POST means only that data has been supplied to the
>> process, to do with as it wishes. As far as HTTP is concerned, the request
>> was successfully completed.
>I find that statement very surprising.  
>It certainly does not fit with my reading of the start of Section 10.2 
>  "This class of status code indicates that the clients request was
>   successfully received, understood AND ACCEPTED"
>and 10.2.1
>   "The request has succeeded"
>It seems I should understand "succeeded" as nothing more than "delivered
>and understood".  

That is the definition of POST.  If you want more semantics than that,
you need to define new status codes, but it makes no difference to a
client whether or not it is a success code because only a human user
could fix such a problem.  Interoperability is not recoverable.

>But my uncertainty applies equally to form data encoded as "GET"....

Same thing.  If the response is consistent, an error message is just
as valid a representation of what was requested as normal content.

The reason I suggested 400 is because the x00 codes are also treated
as the default for each class.  A new 4xx would be better, but not
without a separate Internet Draft that defines the need for the code
and how it can be used to improve interoperability.  For example,
something that defined the set of fields required and optional, or
directed the client to a more appropriate interface.  The reason such
a thing is not in HTTP/1.1 is because nobody has implemented it.

Received on Monday, 29 March 1999 18:43:22 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:06 UTC