RE: SOAP spec.: HTTP binding

Changing horse midstream is a problem but in fact it is not clear that
picking the 200/500 is the biggest challenge as the problem is likely to
appear in the SOAP message while parsing it and so it might as well be
that you have started streaming the SOAP message and have to report an
error somewhere in the middle.

This is different, however, from the semantics of SOAP:Fault which is
defined to talk about the message as a whole. One could argue that it is
for the application to define how to indicate this in the SOAP stream
but I don't think SOAP:Fault should be used here as the semantics are
different.

SOAP is currently silent on this and I agree that it probably shouldn't
be. I will add it to the issues list.

[1] http://msdn.microsoft.com/xml/general/soapspec_issues.asp

Henrik 

> I agree with this comment. The requirement that the HTTP 
> binding specify the
> success or failure of the request as the HTTP status limits 
> seems to presume
> a particular processing model in which you know the overall success or
> failure status before you start returning any response (i.e., 
> you are using
> an in-memory model like a DOM).
> 
> I have been developing SOAP processors where:
>   - performance is critical
>   - memory must be constrained, and
>   - the request and/or response size may be very large.
> 
> There is no way I can use a DOM. In this scenario, it is 
> possible that I can
> start returning a response stream (i.e., through chunked 
> transfer encoding)
> without knowing whether the request as a whole will succeed 
> or fail. I have
> no alternative but to set the status code to "200 OK" when I 
> start streaming
> my response.
> 
> This kind of implementation might not be a typical SOAP 
> implementation, but
> I don't think such a useful implementation strategy should be 
> effectively
> excluded.
> 
> I find section 6.2 of [SOAP] unclear in this area. For 
> example, what is a
> "SOAP error"? Does that include application exceptions? I 
> don't see why I
> can't define my response schema in such a way that a Fault 
> element somewhere
> later on in the response body is considered OK.
> 
> I suspect that my approach is not what the authors of SOAP 
> 1.1 had in mind.
> 
> [SOAP] http://www.w3.org/TR/SOAP/
> 
> Andy Neilson
> 
> 
> -----Original Message-----
> From: xml-dist-app-request@w3.org 
[mailto:xml-dist-app-request@w3.org]On
Behalf Of Kevin Koch
Sent: Monday, December 18, 2000 15:59
To: 'xml-dist-app@w3.org'
Subject: SOAP spec.: HTTP binding


>> In 6.2
>
> In case of a SOAP error 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

This doesn't seem right.  It also causes problems for people wishing to
write simple soap clients.  Many HTTP APIs handle HTTP errors very
differently
than standard returns.  Depending upon the API, it is not always
possible to

read the body of an error response.  Further, in my opinion, HTTP errors
should be reserved for actual HTTP server errors, not SOAP request
errors.
This type of functional overloading, although well intentioned, is not
appropriate.

Received on Monday, 18 December 2000 19:19:12 UTC