[
https://issues.apache.org/jira/browse/HTTPCLIENT-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14005918#comment-14005918
]
Karl Wright commented on HTTPCLIENT-1510:
-----------------------------------------
Hi Oleg,
bq. This seems to contradict your previous statement
Call it a language difference then. "internally" means to me "inside
HttpClient".
bq. What am I supposed to make out of all these? This can well be a bug in
HttpClient. I never said otherwise, but so far there is no evidence supporting
this assertion.
Well, I think I can determine where the wrapping occurs, and why. But it will
take a bit of time. If you see anything obvious in the code above, please let
me know. Your simple test passed, so this has to be subtle.
> Expect/continue not working for HttpRequest objects that are implemented with
> an HttpRequestWrapper
> ---------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1510
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1510
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.3.3
> Reporter: Karl Wright
>
> Certain sorts of requests (multipart post being one of them) use
> HttpRequestWrapper internally to wrap the original request. But the
> Expect/Continue processor has this check in it:
> {code}
> if (request instanceof HttpEntityEnclosingRequest) {
> {code}
> That effectively disables expect/continue for all wrapped requests, since
> HttpRequestWrapper is not derived from HttpEntityEnclosingRequest.
> Suggestion: A better way to structure this would be to have a method in
> HttpRequest that the expect/continue processor would call, instead of doing
> an explicit instanceof class check.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
