You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Dmytro Rud (JIRA)" <ji...@apache.org> on 2011/08/26 18:48:29 UTC
[jira] [Created] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
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
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
>>
>>
>>
>
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,
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
>
>
>
[jira] [Commented] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094909#comment-13094909 ]
Aki Yoshida commented on CXF-3768:
----------------------------------
Hi Dan,
Okay. I looked at CXF-981. It's difficult to say what is meant by "partial responses" and by "ws-rm is enabled" in this ticket.
Within the server runtime, we have partial responses at some point when ws-a is enabled. Prior to the change I made for CXF-3768, we had these PR serialized as http 200 responses. And depending on which interceptors are configured, those responses differ:
- http 200 empty soap body (if only ws-a is used as in this ticket or if ws-rm is used but there is no sequence ack attached to this PR).
- http 200 with non empty soap (if ws-rm is used and there is some sequence ack attached).
If Dan Diephaus meant that he didn't want to see those empty soap with http 200 in those ws-a only cases or those ws-rm without any sequence ack attached cases, his issue would be resolved with this change.
I will search for other tickets you suggested.
regards, aki
p.s. I have a question about how I should fix the test cases and whether to keep the fall back option. I will post it to dev@cxf.
> 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
[jira] [Commented] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092774#comment-13092774 ]
Freeman Fang commented on CXF-3768:
-----------------------------------
Hi Aki,
Your solution sounds ok for me.
The rough idea is that we need figure out a way to tell the difference between empty and non-empty partial response(so that use different http return code), and your solution exactly can do it.
And about the "Assign to me" issue, I don't think jira can really warn you that there's another guy to do same operation at the same time, the "Assign to me" request would be processed one by one, that said, the last one would be the assignee. Anyway, we have email notification for jira changes and IMO that's very rare that two guys try to assign same issue to himself at the same time, so we shouldn't worry this too much.
Best Regards.
Freeman
> 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
[jira] [Commented] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092677#comment-13092677 ]
Aki Yoshida commented on CXF-3768:
----------------------------------
The change needed to correct the following issue introduced this regression problem.
CXF-3004 Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack response message
We probably need to introduce another method in MessageUtils to check if the partial response is empty or non-empty so that AbstractHTTPDestination knows which HTTP status code to return.
- no partial response or an empty partial response -> http 202
This is the case for normal oneway calls or oneway calls with ws-a engaged which sets a partial response.
- a non-empty partial response -> http 200
This is the case for oneway calls with ws-a and additionally some interceptors (ws-rm) setting some properties of the partial 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
[jira] [Commented] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094875#comment-13094875 ]
Daniel Kulp commented on CXF-3768:
----------------------------------
I think CXF-981 is related to this or is a duplicate of this. Aki, can you check on that.
Actually, in the WS-* component in JIRA, there are a bunch of open WS-RM and WS-Addressing related open issues that may be related to this or are already implemented.
> 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
[jira] [Resolved] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aki Yoshida resolved CXF-3768.
------------------------------
Resolution: Fixed
Fix Version/s: 2.5
The patch is applied for 2.5.
We had discussion on the potential impact of this change to other part of CXF and decided to make this change only for 2.5 for now.
http://cxf.547215.n5.nabble.com/Adjusting-WS-RM-systests-for-http-202-tt4756114.html
If this change needs to be integrated to 2.4, this ticket can be reopened.
regards, aki
> 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
> Fix For: 2.5
>
>
> 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
[jira] [Commented] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092697#comment-13092697 ]
Freeman Fang commented on CXF-3768:
-----------------------------------
Hi Aki,
Understood and It doesn't matter.
Just ensure we follow same practice when we work on same project.
Btw, you're welcome to take this issue, :-)
Best Regards
Freeman
> 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
[jira] [Commented] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094453#comment-13094453 ]
Aki Yoshida commented on CXF-3768:
----------------------------------
My reply to Dan was sent to dev@cxf and not to this jira. The link to the mail thread is at:
http://cxf.547215.n5.nabble.com/Re-jira-Commented-CXF-3768-HTTP-response-code-202-is-not-set-for-WS-Addressing-partial-responses-tt4746059.html
Basically, I fixed the behavior as described in the above thread. But the problem is that many existing WS-RM systests are failing after this change, as some of their test assertions are counting those empty messages as well.
I need to look into this and restructure those tests to not rely on the number of physical messages but rely on the information exchanged (i.e., real acks).
After I figure this out, I will submit the change.
> 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
[jira] [Commented] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092689#comment-13092689 ]
Aki Yoshida commented on CXF-3768:
----------------------------------
Freeman,
I am very sorry. I thought I saw the status as unsigned when I
assigned this issue to me. I saw the issue on Friday and it was on my
browser's cache and the status was still unsigned when I did reload
this page this morning. The page was in my browsers cache. I didn't
see that you had already taken it. I am really sorry. It was not
intended.
regards, aki
> 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
[jira] [Assigned] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aki Yoshida reassigned CXF-3768:
--------------------------------
Assignee: Aki Yoshida (was: Freeman Fang)
> 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
[jira] [Assigned] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang reassigned CXF-3768:
---------------------------------
Assignee: Freeman Fang
> 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: Freeman Fang
>
> 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
[jira] [Commented] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092681#comment-13092681 ]
Freeman Fang commented on CXF-3768:
-----------------------------------
Hi Aki,
Isn't it a good practice that when you assign a issue for yourself, you should check if this issue already assigned to other guys? Or at least you should ping the guy who is the previous assignee if you want to take over an issue?
I'm totally OK with that you take over this issue as you obviously know better about this issue history, however IMHO we should follow some good practice when we work on same project together.
What do you think?
Freeman
> 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
[jira] [Commented] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095931#comment-13095931 ]
Aki Yoshida commented on CXF-3768:
----------------------------------
Regarding the related jira tickets, I found
CXF-366
mods to partial response mechanism to facilitate wider interop
CXF-981
Partial responses are always sent when WS-A is enabled
CXF-366 and CXF-981 both talk about suppressing the superfluous http 200 responses. Additionally, CXF-366 talks about accepting HTTP 200 with no content, which is already implemented in CXF.
So, the patch for this CXF-3768 which suppresses the transmission of HTTP 200 empty SOAP envelope responses, I suppose these both issues can be resolved as well.
I will also create a separate jira ticket to make the client side change that is required for letting the CXF client handle HTTP 202 for the CreateSequence call when the CreateSequenceResponse is sent back to the decoupled endpoint.
regards, aki
> 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
[jira] [Commented] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "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
[jira] [Commented] (CXF-3768) HTTP response code 202 is not set for
WS-Addressing partial responses
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092713#comment-13092713 ]
Aki Yoshida commented on CXF-3768:
----------------------------------
Hi Freeman,
thanks. I'll take the issue. And do you think the suggested solution is alright?
I am introducing a new constant EMPTY_PARTIAL_RESPONSE_MESSAGE in
Message. This is set to Boolean.TRUE along with the existing Boolean
property PARTIAL_RESPONSE_MESSAGE when a partial response message is
created. Later when some component updates the partial response
message, we remove this EMPTY_PARTIAL_RESPONSE_MESSAGE property so
that the AbstractHTTPDestination can decide which http response must
be returned. I tried this out and it seems to be working fine.
I would appreciate your comments.
Thanks.
regards, aki
p.s. I'll double check the status next time when I am taking an issue,
but I am worried what will happen when two people push "Assgin to me"
button around the same time, whether the second person will get some
warning or error message and not getting the issue assigned.
> 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