- 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
>> 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. > >Really???!!!! > >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. ....Roy
Received on Monday, 29 March 1999 18:43:22 UTC