Re: XMLP WG Issue 12

* Eric Jenkins <ejenkins@engenia.com> [2001-05-31 17:21-0400]
> Section 6.2 of the XMLP/SOAP 1.1 spec says:
> XMLP/SOAP over 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 XMLP/SOAP component was
> successfully received, understood, and accepted etc.
> If an error occurs while processing the request, the XMLP/SOAP HTTP server
> MUST issue an HTTP 500 "Internal Server Error" response and include a
> XMLP/SOAP message in the response containing a XMLP/SOAP fault (see section
> 4.4) indicating the XMLP/SOAP processing error.
> 
> I believe that there is some ambiguity in the second paragraph and futher,
> that the ambiguity centers around the notion of the "XMLP/SOAP HTTP server".
> This implies that the HTTP server and the SOAP server are inextricably bound
> into a single server.  

The HTTP/1.1 specification[1] uses the term server[2] as "an
application program that accepts connections in order to service
requests by sending back responses." In HTTP-land, my understanding is
that an XMLP/SOAP processor reached using HTTP is a server.

> Is seems possible, if not neccessarily likely, that a site would host a SOAP
> server separate from, but in communication with, the HTTP server.  Further,
> it is also possible (perhaps even less likely) that the communication
> channel between the HTTP server and the SOAP server would be used by some
> other server (RPC, SMTP?) to pass SOAP messages to the SOAP server. In this
> case, in order to generate the 500 error in response to a SOAP Fault, either
> the HTTP server would need to parse the returned value from the SOAP server
> or the SOAP server would have to recognize the local source of the message
> (HTTP server, RPC server, SMTP server) and send back an out-of-band error
> information specific to the local source of the message.

This is true, but from the HTTP client's point of view, all this is
hidden. If there is another communication after the HTTP server
received the request, there will be some piece of code to carry the
request on anyway.

> Perhaps an even more central question is this: Is the HTTP server merely
> part of the transport level upon which the XMLP/SOAP server (in the
> Application level) has been layered or does the HTTP-SOAP binding mean that
> the two servers co-exist within the same OSI level?  (Maybe if we answer
> this question, then we can resolve both this issue and also the SOAPAction
> issue:)  If we decide that they fall into two separate levels, then I
> believe, we will have a difficult time arguing that the SOAP server
> (application level) should be mucking with the HTTP server (transport
> level).  If we decide that they fall into the same level, (both application
> level as Henrik has proposed) then it seems less problematic to have one
> communicating behavior information to the other.

They are both application-level protocols. The XMLP abstract model
sees HTTP as an underlying protocol though.

> If we decide that the HTTP server is merely a transport mechanism, then my
> recommendation is that the spec indicate that a 200 should be returned in
> all cases where the message was successfully received by the SOAP processor
> (whether or not a SOAP fault was generated) and the message sender is
> responsible for parsing the response to determine if a SOAP Fault occurred.
> 
> Note that if we change the XMLP/SOAP spec to differentiate the HTTP
> processor from the SOAP processor, then we will need to futher qualify which
> processor was processing the request when the error occurs and will need to
> specify the return value for both conditions along with a rationale for our
> specification.

I think that dividing the world into 2 categories (200 and 500) is
somewhat simplistic. The definition of the 500 error code[3] is:

  10.5.1 500 Internal Server Error
   
   The server encountered an unexpected condition which prevented it from
   fulfilling the request.

and the 5xx errors[4] are defined as:

   Response status codes beginning with the digit "5" indicate cases in
   which the server is aware that it has erred or is incapable of
   performing the request.

If the client forgot to include an authentication or a payment block,
a 401[5] or 402[6] would be more appropriate, since it is a
client-side problem, not a server-side error. My understanding of 500
is that it is the server's fault.

> Finally, I have listed some scenarios that we may want to discuss the return
> values for at the f2f:

Let me give a try to this one, it might clear up my mind. :-)

> HTTP Server attempts to start SoapProcessor to handle aSoap message and and
> the SoapProcessor crashes

This is a server-side error, and should be a 500.

> 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.

I assume that URL here is the request URL. I think a 404 should be
returned.

If it is a SOAPAction URI, it is supposed to be a hint, so it should
not be dereferenced.

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

This one is interesting. It is a client-side problem, so the 5xx
family does not seem appropriate.

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

200[7] meaning that the request succeeded, I don't think that it is
true. I am uncomfortable about 500 though, because of the reasons
(server-side error) cited above.

> Here is a scenario that am unsure if it is valid, but I think it is
> interesting:  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.  (I'm not sure, but in this
> case it seems like I would want the return code to be 500, which goes
> against everything thay I was arguing for previously).

I think that in that case the server could not handle the request, so
a 500 would make sense.

  1. http://www.w3.org/Protocols/rfc2616/rfc2616.html
  2. http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.3
  3. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.1
  4. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5
  5. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2
  6. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.3
  7. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

Received on Thursday, 31 May 2001 18:32:58 UTC