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
  • Richard Salz
    Damn, I keep getting that wrong. Thanks Glenn /r$ -- SOA Appliances Application Integration Middleware
    Message 1 of 6 , Aug 16 10:36 AM
    • 0 Attachment
      Damn, I keep getting that wrong. Thanks Glenn
      /r$
      --
      SOA Appliances
      Application Integration Middleware
    • 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 2 of 6 , Aug 20 3:09 AM
      • 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.