Issue #12: HTTP Status Codes 500 v 200

Folks,

I pick up the action on last XMLP-WG phone conference to summarise the
discussion around Issue #12
(http://www.w3.org/2000/xp/Group/xmlp-issues#x12) the (HTTP status 500 v
200). At the moment I have avoided taking the 'brave' step of proposing a
resolution - I have tried to 'capture' and summarise the significant
arguments on both sides of the discussion. I would also  recommend the
reading of the whole of section 8 (only 1.5 pages) of [4],  Keith Moore's
Internet Draft "On the use of HTTP as a Substrate for Other Protocols" prior
to discussion at the F2F.

Below, I've separated arguments into those  "against 5xx" and those "against
2xx". Maybe I should frame these more positively as "for 2xx" and "for
5xx"... but I think the complements of the arguments don't necessarily
follow - arguing why 5xx is bad is not the same as arguing why 2xx is good.
I have also added a (no-exhaustive) list of questions that we ought to be
able to answer definitively when this issue has been resolved (including the
scenario questions from Eric Jenkins [11]).

Many thanks,

Stuart Williams
HP Labs, Bristol
--

Issue #12 (http://www.w3.org/2000/xp/Group/xmlp-issues#x12)
---------

Description: "SOAP and HTTP status codes (200 vs. 500 etc.)"
------------

Characterisation:
-----------------

Section 6.2 of the SOAP/1.1 [1] and XMLP/SOAP [2] states:

"6.2 SOAP HTTP Response
SOAP HTTP follows the semantics of the HTTP Status codes for communicating
status information in HTTP. For example, a 2xx status code indicates that
the client's request including the SOAP component was successfully received,
understood, and accepted etc.

In case of a SOAP error while processing the request, the SOAP HTTP server
MUST issue an HTTP 500 "Internal Server Error" response and include a SOAP
message in the response containing a SOAP Fault element (see section 4.4)
indicating the SOAP processing error."

There is discussion of whether it is appropriate to use the HTTP 5xx status
code to signal the failure of a SOAP processor to process a message
delivered in an HTTP POST request message. 

As background reading with respect to this issue, Section 8 of Keith Moore's
Internet Draft "On the use of HTTP as a Substrate for Other Protocols" [4]
offers guidelines that are directly targetted at this issue. These
guidelines contain advice with respect to the use of both 200 and 500 for
reporting errors in layered applications.

[1] http://www.w3.org/TR/SOAP/#_Toc478383529
[2] http://www.w3.org/2000/xp/Group/1/04/17/xmlp-soap-01#_Toc478383529
[3] http://ietf.org/rfc/rfc2616.txt
[4] http://www.normos.org/ietf/draft/draft-moore-using-http-01.txt

Arguments offered against the using 5xx status code:
----------------------------------------------------

* 5xx signals a failure internal to the HTTP server itself. It is wrong to
use a 5xx status code to signal SOAP processing failures. HTTP failures and
SOAP failures are orthogonal. At the HTTP level/layer, conveyance of SOAP
Fault in the HTTP POST response message is success from an HTTP
point-of-view and should be signalled with a 2xx HTTP status code.
[5,5a,5b,5c]

[5]
http://discuss.develop.com/archives/wa.exe?A2=ind0004&L=soap&F=&S=&P=31774
[5a]
http://discuss.develop.com/archives/wa.exe?A2=ind0004&L=soap&F=&S=&P=32002
[5b] http://discuss.develop.com/archives/wa.exe?A2=ind0004&L=soap&P=32800
[5c] http://discuss.develop.com/archives/wa.exe?A2=ind0004&L=soap&P=33037

* Streaming: The requirement to use an HTTP 5xx status code to signal a SOAP
processing failure requires that sufficient processing of SOAP message to
determine the success/failure of SOAP processing before the HTTP status line
can be issued with the 'correct' 2xx/5xx status code. In general, this tends
toward fully processing an inbound SOAP message before the issuing of any
part of the HTTP POST response and make streaming processing of the SOAP
message and 'on-the-fly' generation of the HTTP POST response message
(carrying a SOAP message or a SOAP fault). 

[There are also 'bigger' issues about the discovery of errors part way
through message processing  when some part of a 'response' message has been
streamed] [6,6a,6b]

[6]  http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0196.html
[6a] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0197.html
[6b] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0204.html

* Some HTTP servers (origin and/or intermediary) *may* rewrite the body of
an HTTP 5xx POST response message with some 'helpful' (human) user friendly
message in place of the SOAP fault. [7,7a]

[7]  http://lists.w3.org/Archives/Public/xml-dist-app/2000Jun/0031.html
[7a]
http://discuss.develop.com/archives/wa.exe?A2=ind0004&L=soap&F=&S=&P=32409

* Some practical difficulties in generating HTTP 5xx POST response messages
with full control over Content-Type and Body content. [This one seems a bit
spurious]. [8]

[8]
http://discuss.develop.com/archives/wa.exe?A2=ind0008&L=SOAP&P=R21448&D=0&H=
0&O=A&T=1

Arguments against the use of 2xx status codes:
----------------------------------------------
* HTTP/SOAP are application protocols. Thinking of them as separate layers
is a mistake. HTTP is an application protocol, not a tranpsort. Given the
definition of the HTTP 5xx status codes in RFC2616 [3]:

"10.5.1 500 Internal Server Error

   The server encountered an unexpected condition which prevented it
   from fulfilling the request."

5xx is exactly the right status code to signal the failure of the HTTP/SOAP
server. 2xx would suggest that the SOAP processor had operated successfully.
[9]

[9]
http://discuss.develop.com/archives/wa.exe?A2=ind0004&L=soap&F=&S=&P=33153

* Correct operation of other web applications: search engines, proxies,
annotation engines etc. rely on the correct use of HTTP status codes. Making
inappropriate use of 2xx status codes to will damage the operation of these
(pre-existing) web applications. Must observe HTTP semantics [10,10a].

From [10]:

"It is part of life when living within HTTP (which is a transfer protocol
and not a transport protocol) - HTTP owns the message and HTTP status codes
are for the complete message - you can't have partial success or partial
failure for the HTTP message."

[10]  http://discuss.develop.com/archives/wa.exe?A2=ind0004&L=soap&P=32678
[10a] http://discuss.develop.com/archives/wa.exe?A2=ind0004&L=soap&P=32915

Questions:
----------
1) Should the HTTP status code reflect the outcome of an XMLP/SOAP
processing? i.e. should HTTP say "Ok, here's the reply" independently from
whether processing was successful or not.Should HTTP reflects the outcome of
an XMLP/SOAP processing?

2) Is it the case that all SOAP Fault messages carried in HTTP POST
responses should have the same HTTP status code? 

3) Are the only SOAP message carried in an HTTP POST response with a status
code of 5xx SOAP Faults?

4) In the following scenarios (from Eric Jenkins [11]) what HTTP status
codes should be returned.

	a) HTTP Server attempts to start SoapProcessor 
	   to handle a Soap message and and the 
	   SoapProcessor crashes

	b) HTTP Server recognizes a Soap message (because 
	   of SOAPAction?) but the URL is non-existent, 
	   i.e., SoapProcessor might have handled it just 
	   fine but the server found some flaw in the header.

	c) HTTP Server hands a Soap message to the 
	   SoapProcessor but the message envelope is ill-formed

	d) HTTP Server hands a Soap message to a SoapProcessor 
	   requesting a stockprice for a non-existent stock

	e) The SoapProcessor is actually not the destination 
	   but is only an intermediary, and the message is 
	   being transported via HTTP, and the SoapProcessor 
	   generates a mustUnderstand Fault.

[11] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0369.html

Received on Saturday, 2 June 2001 17:07:49 UTC