Re: XMLP WG Issue 12

Some comments interspersed below.

Cheers,

Chris

Hugo Haas wrote:
> 
<snip/>
> 
> > 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,

Quite likely. In fact, with a dual fire-walled environment (as many enterprises
employ) this would be quite common.

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

I'm not sure I follow the above. It may be transparent to the client,
but it needs to be addressed by the intermediary HTTP server. 

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

The issue of translating a SOAP Fault from one protocol binding to another
(HTTP in this case) remains key. It would be the responsibility of the
HTTP server to parse the SOAP message, recognize it as a SOAP Fault
and generate the 500 status on the return trip to the initiating "client"
(or peer as the case may be).

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

One must also consider the case of a SOAP Fault, carried over HTTP
in a one-way messaging scenario (e.g when the "response" is sent asynchronously,
possibly over a separate channel via an HTTP POST to the other "initiating"
SOAP service.

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

Ahhh, but in the case where the SOAP server and the HTTP server are
the same process, nothing is returned;-) The connection is broken.

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

Indeed, the SOAP server would never see the message to generate a fault.

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

No? If the hint is taken to imply the "intent" and the SOAP server
doesn't understand that intent, a SOAP Fault would (IMHO) be appropriate.
Of course, the SOAP1.1 spec doesn't address this case. If we do
perserve SOAPAction, then I would like to see this clarified (what
processing is expected in the face of a SOAPAction that is not understood
by the recipient of the message).

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

The root cause may be a client side problem, but a strict interpretation
of the 500 status suggests that a 500 is still a valid response.

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

e.g. The unexpected condition is a malformed envelope.

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

In this case, I tend to agree, assuming that the SOAP application uses
a SOAP Fault to communicate an application error as opposed to a
SOAP server exception. The application worked just fine, but the
stock symbol is not in its tables. "Probable User Error" (the old-timers
may recall this one;-) In this case, it is more than likely that the
error needs to be propogated back to the initiating application, the SOAP
server (client) that sent the message with the unknown stock symbol
probably wants this information. The SOAP server shouldn't concern itself 
that the target application had heartburn regarding the stock symbol
requested.

> 
> > 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 19:08:24 UTC