Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack response message

I originally posted this issue on cxf-dev mailing list in last june.
http://mail-archives.apache.org/mod_mbox/cxf-dev/201006.mbox/%3CAANLkTikVG6ULDcj9gkrnfGcks90S5zVcYDrZ79sKxI9G@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