RE: Issue #12 closed

From the mail on the xml-dist-app mailing list, it doesn't
look like this issue is "closed", in the sense that there
is continued discussion.

And I don't think there has been a substantive response to
the comments I made about the risks inherent in using
"500 sever error" for SOAP faults.

I would expect a substantive response before considering the
issue closed.

Larry
-- 
http://larry.masinter.net


> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Wednesday, October 03, 2001 1:00 PM
> To: LMM@acm.org; xmlp-comments@w3.org; Christopher Ferris
> Subject: Issue #12 closed
> 
> 
> Issue #12 [1] has been closed. 
> 
> The following substitution text, agreed to by the WG on the 
> 10/3/2001 con-call, 
> has been added to the SOAP1.2: Part 2 Adjuncts specification
> section 6.3.
> 
> Cheers,
> 
> Chris
> 
> [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x12
> 
> 6.3 SOAP HTTP Response
> 
>         SOAP over HTTP as defined for this default binding 
> follows the semantics 
> 	of the HTTP Status codes for communicating status information in
>         HTTP. 
> 
> 6.3.1 HTTP 2xx Successful
> 
>         A 2xx status code indicates that the request, including 
> the SOAP message 
> 	component, was successfully received, understood, and accepted by
>         the receiving SOAP processor. 
>                 - A 200 OK status SHALL be used to communicate 
> that a SOAP message is 
> 		being conveyed within the entity body of the HTTP response.
>                 The response SOAP message SHALL be implicitly 
> correlated with the 
> 		request SOAP message sent in the HTTP POST operation. 
>                 - A 202 Accepted status MAY be returned by the 
> server to indicate 
> 		that the request SOAP message has been received, 
> but has not been
>                 processed. 
>                 - A 204 No Content status SHALL be used to 
> communicate that the SOAP 
> 		message has been successfully processed by the SOAP 
> application. As 
> 		stipulated in [5], the 204 response MUST NOT 
> include a message body.  
> 
> 6.3.2 HTTP 3xx Redirection
> 
>         No SOAP specific behavior is associated with the 3xx 
> status codes. A SOAP client 
>         SHOULD be prepared to receive and process a 3xx status 
> code as defined in RFC2616 
>         section 10.3. 
> 
> 6.3.3 HTTP 4xx Client Error
> 
>         In general, a SOAP HTTP client SHOULD be prepared to 
> handle any of the 4xx 
> 	class of HTTP status codes. However, the following status codes
>         have specific meaning within the context of this SOAP 
> binding to HTTP. 
>                 - A 400 Bad Request status SHALL be returned in 
> the event that the 
> 		SOAP message contained within the body of an HTTP 
> request message
>                 is not well formed XML or in the case where a 
> SOAP envelope was expected 
> 		in the body of the HTTP POST request and none was present. 
>                 - A 405 Method Not Allowed status MAY be returned 
> in the event that the 
> 		method specified in the HTTP request, containing a 
> SOAP message, 
> 		is not POST. As specified in RFC2616, the HTTP 
> response MUST include 
> 		an Accept header that includes at least POST. 
>                 - A 415 Unsupported Media Type status code SHALL 
> be returned in the 
> 		event that the encapsulation mechanism used for the 
> SOAP message in the 
> 		HTTP request is unsupported by the server. 
> 
> 6.3.4 HTTP 5xx Server Error
> 
>         If an error occurs while processing a SOAP HTTP message, 
> that is not covered
> 	by any of the conditions expressed above in section 6.3.2, 
> 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 (see 
> section 4.4) indicating 
> 	the SOAP processing error.

Received on Wednesday, 3 October 2001 17:58:02 UTC