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
    ... SOAP 1.1 requires that faults be returned with HTTP status 500. SOAP 1.1 does not require that HTTP never send 500 under any other circumstances. ... SOAP
    Message 1 of 6 , Aug 16, 2006
    • 0 Attachment
      > 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?

      SOAP 1.1 requires that faults be returned with HTTP status 500. SOAP 1.1
      does not require that HTTP never send 500 under any other circumstances.
      :) It can't do that, and SOAP 1.1 has an unfortunate intermingling of the
      SOAP and HTTP layers. This is fixed in SOAP 1.2, which says that faults
      use status 200 as well.

      /r$

      --
      SOA Appliances
      Application Integration Middleware
    • Glen Daniels
      ... Um, nope. See table of response codes here: http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-reqbindwaitstate SOAP 1.2 did clarify things, but it
      Message 2 of 6 , Aug 16, 2006
      • 0 Attachment
        Hi Rich:

        >> 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?
        >
        > SOAP 1.1 requires that faults be returned with HTTP status 500. SOAP 1.1
        > does not require that HTTP never send 500 under any other circumstances.
        > :) It can't do that, and SOAP 1.1 has an unfortunate intermingling of the
        > SOAP and HTTP layers. This is fixed in SOAP 1.2, which says that faults
        > use status 200 as well.

        Um, nope. See table of response codes here:

        http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-reqbindwaitstate

        SOAP 1.2 did clarify things, but it clarified them in an effort to be
        more in-line with the HTTP spec (sender errors are 4xx, etc), which
        allows MORE status codes, not less.

        --Glen
      • Richard Salz
        Damn, I keep getting that wrong. Thanks Glenn /r$ -- SOA Appliances Application Integration Middleware
        Message 3 of 6 , Aug 16, 2006
        • 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 4 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.