Re: HTTP/1.1 Error Responses

    > Date: Wed, 24 Mar 1999 13:43:01 -0800
    > From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
    > 
    > >My question concerns the appropriate response code to use when rejecting
    > >a request as incomplete or otherwise unacceptable.  For instance, if
    > >the users submits a form without supplying a value for a necessary
    > >field (say an email address), or with an in-appropriate value (say a
    > >non-existent file type).  
    > >
    > >The server process detects this and wants to reply to say that it
    > >has rejected the request.  What code should be used in the HTTP header?
    > >
    > >Typically, I suspect a CGI application will use "200 OK", even though the
    > >body of the message then says "I can't do that because....".  However,
    > >Section 10.2.1 says that "200 OK" means the request has succeeded, which it
    > >hasn't....
    > 
    > 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".  

My example of a request rejected because of missing or inappropriate data
has surely no more "succeeded" than an attempt to execute a cgi file with
no execute permission---and none of the servers I have used return "200 OK"
for that....

    > >It seems that a "4xx" code would be right.  But which one?  
    > 
    > Either 200 or 400.  

But 400 explicitly says it deals with requests that could not be
understood because of "malformed syntax".  My worry is when there
is a problem iwht the content of the request.

    > None of the others are appropriate because they refer
    > to specific HTTP interoperability concerns, not to POST data.

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

    > 
    > ....Roy

Robert.

--------------------------------------------------------------------------
Robert Inder,                               (http://www.hcrc.ed.ac.uk/~robert/)
NEDO Visiting Fellow, Electrotechnical Laboratory (ETL) (http://www.etl.go.jp/)
                      Umezono 1-1-4, Tsukuba, Ibaraki 305, JAPAN
     Research Fellow, HCRC, Edinburgh University    (http://www.hcrc.ed.ac.uk/)
		      2, Buccleuch Place, Edinburgh EH8 9LW SCOTLAND
--------------------------------------------------------------------------

Received on Monday, 29 March 1999 05:33:34 UTC