[
https://issues.apache.org/jira/browse/CXF-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida resolved CXF-366.
-----------------------------
Resolution: Fixed
Fix Version/s: 2.5
This issue is strongly related to CXF-3768, which has been resolved for 2.5.
Therefore, I am setting this status to resolved.
regards, aki
> mods to partial response mechanism to facilitate wider interop
> --------------------------------------------------------------
>
> Key: CXF-366
> URL: https://issues.apache.org/jira/browse/CXF-366
> Project: CXF
> Issue Type: Improvement
> Components: Transports, WS-* Components
> Reporter: Eoghan Glynn
> Assignee: Aki Yoshida
> Fix For: 2.5
>
>
> An extended discussion on cxf-dev about partial responses identified a number
> of modifications that would facilitate wider interoperability with other
> WS-RM implementations.
> - Currently we expected partial responses received over HTTP to have response
> code 202. However we should also be tolerant to Systinet partial response to
> oneway invocations with response code 200.
> - Currently when checking for a partial response in the HTTPConduit code, we
> determine if the HTTP entity-body is non-empty on the basis on the
> content-length header. We should instead use a non-null content-type as the
> primary indicator of an non-empty entity-body.
> Another interop-friendly improvement would be to supress sending the partial
> response message where there are no non-WS-A headers set by the outgoing
> interceptor chain (e.g. if WS-RM doesn't have any pending outgoing ACKs).
> This could be implemented by interposing a buffering output stream for the
> partial response, and checking that it contained some non-WS-A header before
> flushing it to the wire, otherwise discarding the response body.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
