Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] If a service doesn't return soap faults, but just a 500 status code, does that violate any spec?

Expand Messages
  • Steve Loughran
    ... but we do stick the original Http error code in there somewhere so you can distinguish your 404 from your 302, and maybe even the nested error text,
    Message 1 of 6 , Aug 20, 2006
    • 0 Attachment
      On 8/16/06, Glen Daniels <glen@...> wrote:
      > Hi David:
      >
      > > 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.
      >


      but we do stick the original Http error code in there somewhere so you
      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
      response.

      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.

      -steve
    Your message has been successfully submitted and would be delivered to recipients shortly.