[
https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092677#comment-13092677
]
Aki Yoshida commented on CXF-3768:
----------------------------------
The change needed to correct the following issue introduced this regression
problem.
CXF-3004 Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack
response message
We probably need to introduce another method in MessageUtils to check if the
partial response is empty or non-empty so that AbstractHTTPDestination knows
which HTTP status code to return.
- no partial response or an empty partial response -> http 202
This is the case for normal oneway calls or oneway calls with ws-a engaged
which sets a partial response.
- a non-empty partial response -> http 200
This is the case for oneway calls with ws-a and additionally some interceptors
(ws-rm) setting some properties of the partial response.
> HTTP response code 202 is not set for WS-Addressing partial responses
> ---------------------------------------------------------------------
>
> Key: CXF-3768
> URL: https://issues.apache.org/jira/browse/CXF-3768
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 2.4.2
> Reporter: Dmytro Rud
> Assignee: Aki Yoshida
>
> When asyncronous processing is requested by specifying an endpoint reference
> in the request's ReplyTo WSA header, an immediate acknowledgement should be
> sent with HTTP code 202. Older CXF versions (e.g. 2.2.11) implemented this
> requirement in the method
> {{org.apache.cxf.transport.http.AbstractHTTPDestination#markPartialResponse}},
> but the newer ones (2.4.1, 2.4.2) do not set the HTTP response code
> explicitely, therefore acknowledgements are delivered with code 200.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
