Re: another approach to status codes, etc. in HTTP binding

Mark,

Okay, if we take this approach (reuse application semantics)
to its fullest interpretation, then yes, SOAP Server.* faults
would be reported using 500 and possibly MustUnderstand.*
faults (of course, depending upon your perspective, either
the client is at fault for including a header that the server
doesn't understand or the server is at fault for not understanding
the header;-). However, IMHO, Client.* faults should be reported using 4xx
class of HTTP status codes, not 500. They should probebly be closely 
matched to the various 4xx errors as well.

For instance, say I've got a SOAP-RPC service and I receive
a message that is targetted at a method name I don't recognize.
That would probably be classified as a 405 or possibly a 400
depending upon your perspective.

In addition, I would think that there would need to be some
explicit advice given as to whether an application should
use the SOAP Fault mechanism to report application-level
stuff such as "transaction not completed, insufficient funds".

As I believe has been previously stated, this isn't a Fault
in the same sense as a SEGV. The application successfully processed
the request, it just doesn't have the outcome that the
sender might have preferred;-)

The problem with the current draft is that it exclusively
uses 500 status for all SOAP Faults:

	If an error occurs 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 (see section 4.4) indicating the SOAP processing error.



Cheers,

Chris
Mark Baker wrote:
> 
> Mark Nottingham wrote:
> >
> > On Wed, Jul 18, 2001 at 04:50:42PM -0400, Mark Baker wrote:
> > > >> As SOAP/HTTP reuses HTTP's application semantics (see the charter
> > > >> 8-)
> > > >
> > > > reference?
> > >
> > > 2.4, "Out of Scope; Application Semantics"
> >
> > That's taking it completely out of context. Section 2.4 is a call to
> > avoid the specification of *SOAP* application semantics. How does
> > that translate to a requirement to reuse HTTP's application
> > semantics?
> 
> I didn't say that *SOAP* had to reuse HTTP's application semantics, I
> said "SOAP/HTTP" - meaning the binding - should.  Sorry if that wasn't
> clear.
> 
> Anyhow, how can 2.4 *not* mean to reuse the application semantics of the
> application protocol to which it is bound?  If it doesn't define its
> own, then where do they come from?
> 
> > > I believe the meaning of a SOAP server fault fits within the
> > > definition of 500 (and implicitly, the definition of 5xx).
> >
> > "Server" is being used in two different contexts (their respective
> > documents). An HTTP server is very different from a SOAP server, and
> > may be implemented by a completely different process.
> 
> I look at it this way; sending a SOAP message over HTTP means
> transferring it with HTTP POST  semantics.  So if the transfer of that
> message fails, i.e. if the message cannot be processed (or otherwise
> "accepted as a subordinate", per 2616 sec 9.5) by the resource
> identified by the POST URL, there's an HTTP error to be reported because
> the POST did not succeed.  That the reason for it not being accepted was
> a problem with a processor that isn't the web server, matters not; the
> POST failed, and this has to be communicated.
> 
> Henrik, help me out here! 8-)
> 
> MB