[
https://issues.apache.org/jira/browse/CXF-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-434.
-----------------------------
Resolution: Fixed
Fix Version/s: 2.0.1
> Handle 401 explicitly in HTTPConduit.handleResponse()
> -----------------------------------------------------
>
> Key: CXF-434
> URL: https://issues.apache.org/jira/browse/CXF-434
> Project: CXF
> Issue Type: Sub-task
> Components: Transports
> Reporter: Eoghan Glynn
> Assignee: Eoghan Glynn
> Fix For: 2.0.1
>
>
> If a 401 challenge is received this could be handled explicitly in
> HTTPConduit.handleResponse() (instead of relying on the JVM-wide
> java.net.Authenticator instance).
> The logic should include the following steps:
> 1. check if the last request payload was cached, on the basis of the content
> of type OutputStream.class set on the corresponding outMessage
> 2. if only a standard WrappedOutputStream is set as the message content, then
> a transparent resend is not possible and an exception should be thrown up to
> the application
> 3. if on the other hand, a fully caching output stream is there, then the
> last payload is available for resend, which may be acheived as follows:
> 3a. increment the number of transparent resends we've done for this targetURI
> 3b. get the HttpURLConnection from the previous outMessage via the
> HTTP_CONNECTION property
> 3c. if the threshold for the number of transparent resends has beend reached,
> then turn back on chunking on the HttpURLConnection, unless config has
> explicitly turned this off permanently
> 3d. call HTTP.send() again on the old outMessage to set the content to a
> fresh output stream
> 3e. copy the cached request payload onto the new output stream and flush() &
> close() the stream
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
