You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Aki Yoshida <el...@googlemail.com> on 2011/08/29 14:50:48 UTC
Re: [jira] [Commented] (CXF-3768) HTTP response code 202 is not set
for WS-Addressing partial responses
Hi Dan,
yes. The content and status should match.
It's good that you brought up this decoupled client endpoint case. I
was testing the patched code with non-decoupled cases. But I remember
seeing this http 200 issue with decoupled ws-rm endpoints.
So I just tested the patched code for decoupled ws-rm endpoints and
noticed that the normal responses are now returned with http 202 with
no content but the create sequence's response is still returned with
http 200 with an empty soap, I will see how this can be corrected.
regards, aki
2011/8/29 Daniel Kulp (JIRA) <ji...@apache.org>:
>
> [ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092791#comment-13092791 ]
>
> Daniel Kulp commented on CXF-3768:
> ----------------------------------
>
>
> Well, part of the problem is that CXF is returning a non-empty partial response when it should be returning an empty one. I started looking into this briefly on Friday and noticed that when the incoming request has a reply to to a decoupled dest, we're sending back a 200 with a message with an envelope with an empty body. The 200 is correct there. Instead, it SHOULD be a 202 with an empty 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
>
>
>
Re: [jira] [Commented] (CXF-3768) HTTP response code 202 is not set
for WS-Addressing partial responses
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Dan,
There is a minor problem in fixing the create sequence response case
for decoupled clients that I mentioned.
If we make this change so that the WS-RM provider (or the server) for
a decoupled client returns an HTTP 202 with no content for the
CreateSequence call, the WS-RM client must also be modified to not
expect any response for this call. Unfortunately, it currently expects
an empty SOAP body response because the call is not considered oneway
from the application point of view but it is executed as oneway in the
transport layer as the real create sequence response comes back into
the decoupled endpoint.
So the Client, that is HTTPConduit's response handling code also needs
to be changed to accept HTTP 202 in this case. Should we need to
provide a configuration option to make the server fall back to the old
http 200 behavior so that the old CXF WS-RM clients don't get problems
at executing their create sequence calls or should we just down port
this client side fix to 2.3. et al and document it as an
incompatibility issue for the older CXF with the new ones?
I think we can just fix this behavior and align it with the standard
without providing the fallback behavior option because the problem
will happen only when those very old clients are talking to the
patched 2.4 and 2.5 servers. And those old clients will certainly have
ineroperability issues with other servers as well. How do you think?
Thanks.
regards, aki
2011/8/29 Aki Yoshida <el...@googlemail.com>:
> Hi Dan,
> The reason why the patched code still returned an http 200 with an
> empty soap body for the create sequence's response in a decoupled case
> is that the crease sequence call is not marked as oneway (but the call
> is handled as oneway as its replyTo is not set to one of the anonymous
> addresses).
>
> So I need another change in the AbstractHTTPDestination's response
> status logic to catch this case.
>
> regards, aki
>
>
> 2011/8/29 Aki Yoshida <el...@googlemail.com>:
>> Hi Dan,
>> yes. The content and status should match.
>>
>> It's good that you brought up this decoupled client endpoint case. I
>> was testing the patched code with non-decoupled cases. But I remember
>> seeing this http 200 issue with decoupled ws-rm endpoints.
>>
>> So I just tested the patched code for decoupled ws-rm endpoints and
>> noticed that the normal responses are now returned with http 202 with
>> no content but the create sequence's response is still returned with
>> http 200 with an empty soap, I will see how this can be corrected.
>>
>> regards, aki
>>
>> 2011/8/29 Daniel Kulp (JIRA) <ji...@apache.org>:
>>>
>>> [ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092791#comment-13092791 ]
>>>
>>> Daniel Kulp commented on CXF-3768:
>>> ----------------------------------
>>>
>>>
>>> Well, part of the problem is that CXF is returning a non-empty partial response when it should be returning an empty one. I started looking into this briefly on Friday and noticed that when the incoming request has a reply to to a decoupled dest, we're sending back a 200 with a message with an envelope with an empty body. The 200 is correct there. Instead, it SHOULD be a 202 with an empty 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
>>>
>>>
>>>
>>
>
Re: [jira] [Commented] (CXF-3768) HTTP response code 202 is not set
for WS-Addressing partial responses
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Dan,
The reason why the patched code still returned an http 200 with an
empty soap body for the create sequence's response in a decoupled case
is that the crease sequence call is not marked as oneway (but the call
is handled as oneway as its replyTo is not set to one of the anonymous
addresses).
So I need another change in the AbstractHTTPDestination's response
status logic to catch this case.
regards, aki
2011/8/29 Aki Yoshida <el...@googlemail.com>:
> Hi Dan,
> yes. The content and status should match.
>
> It's good that you brought up this decoupled client endpoint case. I
> was testing the patched code with non-decoupled cases. But I remember
> seeing this http 200 issue with decoupled ws-rm endpoints.
>
> So I just tested the patched code for decoupled ws-rm endpoints and
> noticed that the normal responses are now returned with http 202 with
> no content but the create sequence's response is still returned with
> http 200 with an empty soap, I will see how this can be corrected.
>
> regards, aki
>
> 2011/8/29 Daniel Kulp (JIRA) <ji...@apache.org>:
>>
>> [ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092791#comment-13092791 ]
>>
>> Daniel Kulp commented on CXF-3768:
>> ----------------------------------
>>
>>
>> Well, part of the problem is that CXF is returning a non-empty partial response when it should be returning an empty one. I started looking into this briefly on Friday and noticed that when the incoming request has a reply to to a decoupled dest, we're sending back a 200 with a message with an envelope with an empty body. The 200 is correct there. Instead, it SHOULD be a 202 with an empty 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
>>
>>
>>
>