Re: [soapbuilders] If a service doesn't return soap faults, but just a 500 status code, does that violate any spec?
- On 8/16/06, Glen Daniels <glen@...> wrote:
> Hi David:but we do stick the original Http error code in there somewhere so you
> > I need to use an outside web service that I've discovered has an
> > unconventional trait. If something goes wrong, either in the input
> > message body, message headers, or just something screwy in the service,
> > instead of returning a SOAP fault, it just returns a 500 status code.
> > My question is, does that violate in principle or spirit any of the
> > related specifications in this domain? If so, could someone give me a
> > pointer to documentation of that fact?
> I don't think this violates any spec. It's certainly more polite to
> return a SOAP fault, but there will always be cases where a problem
> actually occurs down at the HTTP layer, and your SOAP engine never even
> gets called (i.e. imagine a poorly-configured Java servlet) - so it
> can't very well produce a SOAP fault.
> I'm not sure how other systems deal with this, but the Axis SOAP client
> code, for instance, will wrap any HTTP errors (or in fact any
> socket-level errors, etc) in a "virtual SOAP fault" so fault processing
> is consistent for the application coder.
can distinguish your 404 from your 302, and maybe even the nested
error text, suitably escaped.
Any soap client that talks SOAP over HTTP has to expect the full gamut
of HTTP error codes, and they have to expect that bits of the
infrastructure can return HTTP error code+text/html commentary,
I had to deal with support call once against a homegrown client where
my service was 'returning bad XML'; their XML parser was rejecting the
After getting the URL, we had this great conversation
"it is bad XML, but that's because its an IIS 401 response text"
"dont do that then"
"we arent. we arent using IIS"
They had a the wrong url, and werent checking response code or content type.
Sometimes error response pages that come back as 200 with human-only
text cause problems, but the real bane of my life is proxy servers
that try and do clever things. That and web clients that do helpful
text rather than show the original message. Maybe the next iteration
of client apps should come with an XSD to handle SOAPFaults better.
Indeed, I'd return an XML PI in the soapfault that pointed a good XSD
if PI's werent forbidden by the SOAP spec.