2011/9/2 Dennis Sosnoski <d...@sosnoski.com>: > 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 > (http://www.ws-i.org/Profiles/BasicProfile-1.1.html#HTTP_Success_Status_Codes): > > /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. Thanks. regards, aki > > - Dennis > >
