cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aki Yoshida (JIRA)" <>
Subject [jira] Updated: (CXF-3004) Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack response message
Date Mon, 20 Sep 2010 16:20:33 GMT


Aki Yoshida updated CXF-3004:


as my code fragment text in the above description was garbled,
attaching the diffs and the modified java files for 2.2.x and 2.3.x for better references.

> Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack response message
> ---------------------------------------------------------------------------------------
>                 Key: CXF-3004
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 2.2.9, 2.2.10
>            Reporter: Aki Yoshida
>             Fix For: 2.3, 2.2.11
>         Attachments:
> I originally posted this issue on cxf-dev mailing list in last june.
> 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
>               }
>               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()),
>                   header.add(holder);
> For 2.3.0-SNAPSHOT, however, this change alone does not solve the problem because  org.apache.cxf.transport.http.AbstractHTTPDestination
> overwrites the http response code for the partial response message in its updateResponeHeaders
> 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.

View raw message