XMLP WG Issue 12

Stuart,
On the XMLP WG telecon yesterday, I believe that you volunteered to write up
a description of Issue 12?  

If so, I wanted to raise some issues with you (and the group) that have come
up in the past and am sure will come up at the f2f.  

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.  

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.

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.

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.

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

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

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.

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

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

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

Eric A. Jenkins
Engenia Software, Inc.
703.234.1416

Received on Thursday, 31 May 2001 17:21:46 UTC