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

Handling HTTP response 204, 'no content'

Expand Messages
  • Steve Loughran
    Axis (1.1RC) currently generates a HTTP 204 response in obscure circumstances, which I am yet to track down. It is effectively done when a request gets
    Message 1 of 4 , Mar 25, 2003
    • 0 Attachment
      Axis (1.1RC) currently generates a HTTP 204 response in obscure
      circumstances, which I am yet to track down. It is effectively done when
      a request gets processed but no response is generated:

      if (responseMsg == null) {
      res.setStatus(HttpServletResponse.SC_NO_CONTENT);
      if(isDebug) log.debug("NO AXIS MESSAGE TO RETURN!");
      ...
      }

      The question is: what are clients going to do when they get this
      response? Continue happily on their way or die horribly?

      The only reference point to date is the Axis client side itself, which
      falls into the "die horribly" category, showing it has an internal
      interop problem.


      [java] org.xml.sax.SAXParseException: Premature end of file.

      How should this be resolved? Should we fix the client to accept a 204
      response, or should the server not ever generate it, throwing a fault
      when it gets into that state (which it does on the HTTP GET handler in
      the same situation)

      And equally critically, what are other client impls likely to do when
      they get a 204 back up the wire? If nothing else can handle it, then
      generating a fault server side seems the only sensible action to do for
      the highly imminent axis1.1 release.

      -Steve

      ffi: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18024
    • Paul Kulchenko
      Steve, ... As far as I understand there is nothing in SOAP1.1 spec that requires 200OK status code to be returned. In fact, spec [1] clearly says: For
      Message 2 of 4 , Mar 25, 2003
      • 0 Attachment
        Steve,

        > How should this be resolved? Should we fix the client to accept a
        As far as I understand there is nothing in SOAP1.1 spec that requires
        200OK status code to be returned. In fact, spec [1] clearly says:

        "For example, a 2xx status code indicates that the client's request
        including the SOAP component was successfully received, understood,
        and accepted etc."

        The situation is little bit different for SOAP1.2 and the only
        documented discussion I could find is this [2]

        "General agreement to resolve these issues by saying that (i) our MEP
        and HTTP binding do not handle 204 and 202 codes because the MEP
        assumes SOAP messages in both the request and response, (ii) other
        MEPs may embody other assumptions such that a SOAP message is not
        expected as a response, and these MEPs may handle 202 and 204
        error codes."

        Request-Response/Response MEP operation descriptions [3] include only
        200OK code.

        Best wishes, Paul.

        P.S. I believe SOAP::Lite should be able to handle both 202 and 204
        HTTP codes just fine (althought I may need to doublecheck).

        [1] http://www.w3.org/TR/SOAP/#_Toc478383529
        [2] http://www.w3.org/2000/xp/Group/2/05/15-minutes.html
        [3] http://www.w3.org/TR/soap12-part2/#http-msgexop

        --- Steve Loughran <steve_l@...> wrote:
        >
        > Axis (1.1RC) currently generates a HTTP 204 response in obscure
        > circumstances, which I am yet to track down. It is effectively done
        > when
        > a request gets processed but no response is generated:
        >
        > if (responseMsg == null) {
        > res.setStatus(HttpServletResponse.SC_NO_CONTENT);
        > if(isDebug) log.debug("NO AXIS MESSAGE TO RETURN!");
        > ...
        > }
        >
        > The question is: what are clients going to do when they get this
        > response? Continue happily on their way or die horribly?
        >
        > The only reference point to date is the Axis client side itself,
        > which
        > falls into the "die horribly" category, showing it has an internal
        > interop problem.
        >
        >
        > [java] org.xml.sax.SAXParseException: Premature end of file.
        >
        > How should this be resolved? Should we fix the client to accept a
        > 204
        > response, or should the server not ever generate it, throwing a
        > fault
        > when it gets into that state (which it does on the HTTP GET handler
        > in
        > the same situation)
        >
        > And equally critically, what are other client impls likely to do
        > when
        > they get a 204 back up the wire? If nothing else can handle it,
        > then
        > generating a fault server side seems the only sensible action to do
        > for
        > the highly imminent axis1.1 release.
        >
        > -Steve
        >
        > ffi: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18024
        >
        >
        > ------------------------ Yahoo! Groups Sponsor
        >
        > -----------------------------------------------------------------
        > This group is a forum for builders of SOAP implementations to
        > discuss implementation and interoperability issues. Please stay
        > on-topic.
        >
        > To unsubscribe from this group, send an email to:
        > soapbuilders-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        >
        >


        __________________________________________________
        Do you Yahoo!?
        Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
        http://platinum.yahoo.com
      • Steve Loughran
        Paul Kulchenko says ... Thanks for those minutes; I hadnt seen those before, only the 1.1 and 1.2 specs, and this bit from the current draft of the WS-I basic
        Message 3 of 4 , Mar 25, 2003
        • 0 Attachment
          Paul Kulchenko says
          > "General agreement to resolve these issues by saying that (i) our MEP
          >and HTTP binding do not handle 204 and 202 codes because the MEP
          >assumes SOAP messages in both the request and response, (ii) other
          >MEPs may embody other assumptions such that a SOAP message is not
          >expected as a response, and these MEPs may handle 202 and 204
          >error codes."


          Thanks for those minutes; I hadnt seen those before, only the 1.1 and
          1.2 specs, and this bit from the current draft of the WS-I basic profile:

          http://ws-i.org/Profiles/Basic/2003-01/BasicProfile-1.0-WGAD.html

          "HTTP uses the 2xx series of status codes to communicate success. In
          particular, 200 is the default for successful messages, but 202 can be
          used to indicate that a messages has been submitted for processing.
          Additionally, other 2xx status codes may be appropriate, depending on
          the nature of the HTTP interaction.

          R1124 An INSTANCE MUST use a 2xx HTTP status code for responses that
          indicate a successful outcome of a request.

          R1111 An INSTANCE SHOULD use a "200 OK" HTTP status code for responses
          that contain a SOAP message that is not a SOAP fault.

          R1112 An INSTANCE SHOULD use either a "200 OK" or "202 Accepted" HTTP
          status code for responses that indicate successful HTTP outcome of a
          request but do not contain a SOAP message."
          --------------

          So here we have 'use 2XX for all good responses', and we SHOULD return
          200 or 202 (not 204) for successful requests that dont generate a
          response, but it isnt a MUST.

          I am thinking for WS-I compatibility Axis will return 202 in this
          situation, though I think the client will still trip over its own Sax
          parser when it comes time to process the response.

          -steve
        • Bob Cunnings
          Hi, FWIW the WM implementation returns 204 when processing WS- Routing messages when the SOAP response is being routed along an HTTP reverse path different
          Message 4 of 4 , Mar 25, 2003
          • 0 Attachment
            Hi,

            FWIW the WM implementation returns 204 when processing WS-
            Routing messages when the SOAP response is being routed along
            an HTTP reverse path different from the forward path. The client is
            happy with 204 since it is the originator of the message and thus
            knows that the ultimate receiver of the SOAP response is not itself.

            The use of 204 is prescribed in the WS-Routing spec [1].

            The WM client also expects 204 when the WSDL "one-way"
            message pattern is in use. This is based on the absence of an
            output message in the WSDL definition for the operation.

            Although WS-I Basic Profile promotes 202, IMO 204 "No Content"
            should be considered equally acceptable.

            RC

            [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-
            us/dnglobspec/html/ws-routing.asp

            > Paul Kulchenko says
            > > "General agreement to resolve these issues by saying that (i) our MEP
            > >and HTTP binding do not handle 204 and 202 codes because the MEP
            > >assumes SOAP messages in both the request and response, (ii) other
            > >MEPs may embody other assumptions such that a SOAP message is not
            > >expected as a response, and these MEPs may handle 202 and 204
            > >error codes."
            >
            >
            > Thanks for those minutes; I hadnt seen those before, only the 1.1 and
            > 1.2 specs, and this bit from the current draft of the WS-I basic profile:
            >
            > http://ws-i.org/Profiles/Basic/2003-01/BasicProfile-1.0-WGAD.html
            >
            > "HTTP uses the 2xx series of status codes to communicate success. In
            > particular, 200 is the default for successful messages, but 202 can be
            > used to indicate that a messages has been submitted for processing.
            > Additionally, other 2xx status codes may be appropriate, depending on
            > the nature of the HTTP interaction.
            >
            > R1124 An INSTANCE MUST use a 2xx HTTP status code for responses that
            > indicate a successful outcome of a request.
            >
            > R1111 An INSTANCE SHOULD use a "200 OK" HTTP status code for responses
            > that contain a SOAP message that is not a SOAP fault.
            >
            > R1112 An INSTANCE SHOULD use either a "200 OK" or "202 Accepted" HTTP
            > status code for responses that indicate successful HTTP outcome of a
            > request but do not contain a SOAP message."
            > --------------
            >
            > So here we have 'use 2XX for all good responses', and we SHOULD return
            > 200 or 202 (not 204) for successful requests that dont generate a
            > response, but it isnt a MUST.
            >
            > I am thinking for WS-I compatibility Axis will return 202 in this
            > situation, though I think the client will still trip over its own Sax
            > parser when it comes time to process the response.
            >
            > -steve
            >
            >
            >
            > -----------------------------------------------------------------
            > This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.
            >
            > To unsubscribe from this group, send an email to:
            > soapbuilders-unsubscribe@yahoogroups.com
            >
            >
            >
            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.