cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: Adjusting WS-RM systests for http 202
Date Fri, 02 Sep 2011 08:41:56 GMT
2011/9/2 Dennis Sosnoski <>:
> On 09/01/2011 09:15 PM, Aki Yoshida wrote:
>> As Dennis says in his reply, the RM spec doesn't talk about this
>> transportation binding specific part. The reason, I suppose, is that
>> this is implicitly covered by the normal WS BP profile that recommends
>> the use of HTTP 202 if there is nothing to return.
> Is this actually stated in BP? All I could find was that both 200 and
> 202 responses are allowed for an empty response to a successful request,
> with the comment
> (
> /Despite the fact that the HTTP 1.1 assigns different meanings to
> response status codes "200" and "202", in the context of the Profile
> they should be considered equivalent by the initiator of the request.
> The Profile accepts both status codes because some SOAP implementations
> have little control over the HTTP protocol implementation and cannot
> control which of these response status codes is sent./
> So for BP compliance the client should not care which of these is
> returned by the server.

Hi Dennis,

Okay. You are right. BP technically allows HTTP 200 with no content.
But I think this R1112 rule's allowing 200 for no-content is
controversial, as it puts more burden on the client side to verify
what a valid response is and what is not. If no-content response is
returned always with 202, the client reads the status code and knows
that it's valid to see no content. In contrast, if no-content response
is returned with 200, the client must guess based on the operation
(i.e., oneway or twoway) whether it's valid  to see no content or some
data has been lost. This situation becomes even more complicated when
WS-A is involved and a decoupled endpoint is used.

CXF can handle HTTP 200 with no content for oneway calls, but I
remember some other client implementations (e.g. old Axis) expected
some SOAP content when the status is 200.

>> If I remember it correctly, Axis2/Sandesha uses HTTP 202 with no
>> content for all those responses (e.g., getting the http 202 response
>> at the http port when using a decoupled client port for the real
>> responses/acks). I can check this again. But maybe Dennis could also
>> verify how Axis2 and in particular Metro behave in this case.
> I'll try a decoupled client on Metro and post the results.

Thanks. I looked at some examples of Axis2 and the new behavior can
interoperate with them. But I noticed one thing in the create sequence
behavior for a decoupled endpoint case.

Axis2 sets replyTo to the anonymous address so that the
CreateSequenceResponse comes back directly in the HTTP response,
whereas all the other responses come back to the decoupled endpoint.
In contrast, CXF sets replyTo to  the decoupled endpoint so that the
create sequence response also comes back to the decoupled endpoint.
Although they interoperate each other, I think it would be nice to
provide a configuration option in CXF to also set replyTo to the
anonymous address for the create sequence. How do you think?

This can be a configuration property somewhere in the manager or
sorcePolicy or a request context property. If it goes to the
configuration, I don't exactly where we should put it. I saw you
started to work on the manager config for the version switching
feature. Maybe, you can tell me where you would put it.


regards, aki

>  - Dennis

View raw message