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

Re: [soapbuilders] Handling HTTP response 204, 'no content'

Expand Messages
  • 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 1 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 2 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.