[
https://issues.apache.org/jira/browse/CXF-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3004.
------------------------------
Resolution: Fixed
> Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack
> response message
> ---------------------------------------------------------------------------------------
>
> Key: CXF-3004
> URL: https://issues.apache.org/jira/browse/CXF-3004
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 2.2.9, 2.2.10
> Reporter: Aki Yoshida
> Assignee: Daniel Kulp
> Fix For: 2.3, 2.2.11
>
> Attachments: cxf-3004-fixes.zip
>
>
> I originally posted this issue on cxf-dev mailing list in last june.
> http://mail-archives.apache.org/mod_mbox/cxf-dev/201006.mbox/%3caanlktikvg6uldcj9gkrnfgcks90s5zvcydrz79skx...@mail.gmail.com%3e
> I didn't see any response and unfortunately, I also forgot to follow up on
> this problem. The problem is present in the recently released 2.2.10. I
> observed this problem in 2.2.9, 2.2.10, 2.2.11-SNAPSHOT, and 2.3.0-SNAPSHOT.
> The problem description and possible solutions to fix this issue are given
> below.
> Problem
> When oneway call is received at the server and gets rebased, its response
> message is marked as a partial response. The response code of this partial
> response message is automatically set to 202.
> This behavior of the CXF implementation causes interoperability problems for
> a WS-RM scenario with a non-addressable client (i.e., the
> client that needs to receive WS-RM acknowledgement messages in the
> piggybacked HTTP 200 response). As the response code 202 indicates no
> presence of a valid SOAP envelope, WS-RM acknowledgement messages are not
> correctly processed at those client implementations that follow this rule.
> I think there are several approaches in fixing this issue. One option is to
> revert the status code to 200 in RMSoapInterceptor when the response message
> must be filled with the relevant WS-RM properties. I tested this option with
> 2.2.9, 2.2.10, and 2.2.11-SNAPSHOT, and it works fine.
> Concretely, I modified RMSoapInterceptor to revert the http response code to
> 200 when the rm header is filled with the relevant rm properties.
> In particular, I added the following lines in the encode method of
> org.apache.cxf.ws.rm.soap.RMSoapInterceptor
> }
> Node node = hdr.getFirstChild();
> + if (node != null && MessageUtils.isPartialResponse(message)) {
> + // make sure the ack response is returned as HTTP 200 and
> not 202
> + // message.put(Message.PARTIAL_RESPONSE_MESSAGE, null);
> + message.put(Message.RESPONSE_CODE,
> HttpURLConnection.HTTP_OK);
> + }
> while (node != null) {
> Header holder = new Header(new
> QName(node.getNamespaceURI(), node.getLocalName()), node);
> header.add(holder);
> For 2.3.0-SNAPSHOT, however, this change alone does not solve the problem
> because org.apache.cxf.transport.http.AbstractHTTPDestination always
> overwrites the http response code for the partial response message in its
> updateResponeHeaders method.
> So, in order to avoid this overwriting, I needed to comment out this part
> shown below in the updateResponseHeader shown below.
> protected void updateResponseHeaders(Message message) {
> ! // setting the response to 202 here breaks the ws-rm piggybacked
> ack response
> ! // if (MessageUtils.isPartialResponse(message)) {
> ! // message.put(Message.RESPONSE_CODE,
> HttpURLConnection.HTTP_ACCEPTED);
> ! // }
> Map<String, List<String>> responseHeaders =
> CastUtils.cast((Map)message.get(Message.PROTOCOL_HEADERS));
> if (responseHeaders == null) {
> Alternatively, we could remove the partial response flag of this response
> message at RMSoapInterceptor so that the updateResponseHeaders method would
> not overwrite the response status. However, this interferes with another part
> of the AbstractHTTPDestination class and this approach will require
> additional changes in this class. However, it was not clear to me what
> exactly the semantic definition of the partial response message should be in
> the context of the WS-RM protocol. So I did not pursue this approach.
> Best Regards,
> Aki
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
