cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aki Yoshida (JIRA)" <j...@apache.org>
Subject [jira] Created: (CXF-3004) Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack response message
Date Mon, 20 Sep 2010 15:14:32 GMT
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/%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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message