Inconsistent HTTP response code returned for WS-RM scenarios

[Akitoshi Yoshida <sa...@googlemail.com>]

I noticed an inconsistent HTTP response code in the WS-RM server side
implementation that can lead to interoperability issues. This can be
observed in the sample demo scenario.

The WS-RM spec refers to WS-I Basic Profile for its HTTP binding
behavior and the profile states:

-  R1111 An INSTANCE SHOULD use a "200 OK" HTTP status code on a
response message that contains an envelope that is not a fault.

-  R1112 An INSTANCE SHOULD use either a "200 OK" or "202 Accepted"
HTTP status code for a response message that does not contain a SOAP
envelope but indicates the successful outcome of a HTTP Request.

The first problem is for a decoupled-endpoint case, where non-empty
content is returned with HTTP 202. Concretely, when using a
decoupled-endpoint, http://localhost:9990/decoupled_endpoint, the HTTP
response to the original request should be empty with HTTP 202
Accepted, as the concrete response is returned to this decoupled
endpoint. However, the current implementation returns a non-empty
content with HTTP 202 Accepted, more precisely, the content being a
SOAP envelope with no Body child but with the WS-address fields
filled.

In this case, the response content should be empty. I think the
partial response must be processed differently for this case so that
the response remains empty, as done in OneWayProcessorInterceptor.
This issue may not be critical, as any implementation that receives
HTTP 202 may probably ignore the content even if it is present.

The second problem is for an anonymous-endpoint case, where a valid
non-empty SOAP envelope is returned with HTTP 202. In this case, the
HTTP response to the first message, for CreateSequenceRequest, the
HTTP response is a SOAP envelope with CreateSequenceResponse with HTTP
200 OK. This is fine. However, for the subsequent messages, the HTTP
response is a SOAP envelope with some valid content, like
SequenceAcknowledgement, but returned with status HTTP 202 Accepted.

In this case, the response code should be HTTP 200 OK. It seems, the
HTTP code for oneway services is automatically set to HTTP 202 in
AbstractHTTPDestination. When the partial response content is not
empty, as in the WS-RM with anonymous-endpoint case, the HTTP status
code should be changed somewhere during the partial response handling
to HTTP 200 OK. This issue is more critical, as some implementation
may simply ignore the content when receiving HTTP 202.

Could you comment on this issue?

Thanks.
Best regards, Aki

Re: Inconsistent HTTP response code returned for WS-RM scenarios

[Daniel Kulp <dk...@apache.org>]

On Wednesday 22 September 2010 8:24:39 am Aki Yoshida wrote:
> Hi,
> regarding this HTTP 202 problem for a piggybacked WS-RM ack response,
> I created the jira entry:
> 
> CXF-3004
> Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack
> response message

I'll try an take a look.  Something is definitely strange, at least on trunk.  
I did a wireshark trace on a decoupled ws-a case and saw some strange things.   
A ack in a 202 (instead of 200) along with the client sending an 200 with an 
empty body back for the real response.   

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Inconsistent HTTP response code returned for WS-RM scenarios

[Aki Yoshida <sa...@googlemail.com>]

Hi,
regarding this HTTP 202 problem for a piggybacked WS-RM ack response,
I created the jira entry:

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

regards, aki