[
https://issues.apache.org/jira/browse/HTTPCLIENT-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14005894#comment-14005894
]
Oleg Kalnichevski commented on HTTPCLIENT-1510:
-----------------------------------------------
bq. Certain sorts of requests (multipart post being one of them) use
HttpRequestWrapper internally to wrap the original request
Then, they are supposed to do it correctly or better yet use
HttpRequestWrapper#warp instead of class extension. If future HTTP protocol
revisions define all HTTP methods are entity enclosing, we will have to do away
with HttpEntityEnclosingRequest optional interface, but not until RFC 2616 is
superseded by another RFC.
I see no option other than rejecting the issue as invalid or making it a change
request targeted at FUTURE (5.0 and beyond).
Oleg
> 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]
