Hi Dan, There is a minor problem in fixing the create sequence response case for decoupled clients that I mentioned.
If we make this change so that the WS-RM provider (or the server) for a decoupled client returns an HTTP 202 with no content for the CreateSequence call, the WS-RM client must also be modified to not expect any response for this call. Unfortunately, it currently expects an empty SOAP body response because the call is not considered oneway from the application point of view but it is executed as oneway in the transport layer as the real create sequence response comes back into the decoupled endpoint. So the Client, that is HTTPConduit's response handling code also needs to be changed to accept HTTP 202 in this case. Should we need to provide a configuration option to make the server fall back to the old http 200 behavior so that the old CXF WS-RM clients don't get problems at executing their create sequence calls or should we just down port this client side fix to 2.3. et al and document it as an incompatibility issue for the older CXF with the new ones? I think we can just fix this behavior and align it with the standard without providing the fallback behavior option because the problem will happen only when those very old clients are talking to the patched 2.4 and 2.5 servers. And those old clients will certainly have ineroperability issues with other servers as well. How do you think? Thanks. regards, aki 2011/8/29 Aki Yoshida <[email protected]>: > Hi Dan, > The reason why the patched code still returned an http 200 with an > empty soap body for the create sequence's response in a decoupled case > is that the crease sequence call is not marked as oneway (but the call > is handled as oneway as its replyTo is not set to one of the anonymous > addresses). > > So I need another change in the AbstractHTTPDestination's response > status logic to catch this case. > > regards, aki > > > 2011/8/29 Aki Yoshida <[email protected]>: >> Hi Dan, >> yes. The content and status should match. >> >> It's good that you brought up this decoupled client endpoint case. I >> was testing the patched code with non-decoupled cases. But I remember >> seeing this http 200 issue with decoupled ws-rm endpoints. >> >> So I just tested the patched code for decoupled ws-rm endpoints and >> noticed that the normal responses are now returned with http 202 with >> no content but the create sequence's response is still returned with >> http 200 with an empty soap, I will see how this can be corrected. >> >> regards, aki >> >> 2011/8/29 Daniel Kulp (JIRA) <[email protected]>: >>> >>> [ >>> https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092791#comment-13092791 >>> ] >>> >>> Daniel Kulp commented on CXF-3768: >>> ---------------------------------- >>> >>> >>> Well, part of the problem is that CXF is returning a non-empty partial >>> response when it should be returning an empty one. I started looking >>> into this briefly on Friday and noticed that when the incoming request has >>> a reply to to a decoupled dest, we're sending back a 200 with a message >>> with an envelope with an empty body. The 200 is correct there. Instead, >>> it SHOULD be a 202 with an empty response. >>> >>>> HTTP response code 202 is not set for WS-Addressing partial responses >>>> --------------------------------------------------------------------- >>>> >>>> Key: CXF-3768 >>>> URL: https://issues.apache.org/jira/browse/CXF-3768 >>>> Project: CXF >>>> Issue Type: Bug >>>> Components: WS-* Components >>>> Affects Versions: 2.4.2 >>>> Reporter: Dmytro Rud >>>> Assignee: Aki Yoshida >>>> >>>> When asyncronous processing is requested by specifying an endpoint >>>> reference in the request's ReplyTo WSA header, an immediate >>>> acknowledgement should be sent with HTTP code 202. Older CXF versions >>>> (e.g. 2.2.11) implemented this requirement in the method >>>> {{org.apache.cxf.transport.http.AbstractHTTPDestination#markPartialResponse}}, >>>> but the newer ones (2.4.1, 2.4.2) do not set the HTTP response code >>>> explicitely, therefore acknowledgements are delivered with code 200. >>> >>> -- >>> This message is automatically generated by JIRA. >>> For more information on JIRA, see: http://www.atlassian.com/software/jira >>> >>> >>> >> >
