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