RE: SOAP spec.: HTTP binding

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 18:04:44 UTC