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.10, 2.2.9
Reporter: Aki Yoshida
Fix For: 2.3, 2.2.11
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.
