[
https://issues.apache.org/jira/browse/HTTPCLIENT-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17987373#comment-17987373
]
Oleg Kalnichevski commented on HTTPCLIENT-2378:
-----------------------------------------------
[~thomas-k-dev] Yes, this kind of behavior is to be expected when using the
classic transport. `MonitoringResponseOutOfOrderStrategy` is intentionally not
being used by default as it adds a considerable overhead for TLS connections by
doing an extra read operation in between write operations.
The proper solution to the problem is to ask Jetty developers to respect the
`expect: continue` handshake or switch to the async transport, which can handle
out of sequence responses more gracefully.
Oleg
> Big request bodies and early server reponse yield SocketException instead of
> response
> -------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2378
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2378
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 5.5
> Reporter: Thomas Klambauer
> Priority: Minor
> Attachments: httpclient-bug.zip
>
>
> Hi! We have a problem similar/same as HTTPCLIENT-2093.
> it seems not fixed with the other issue.
> Basically, eg jetty responds early with an HTTP404 if a URL is not found,
> while the HTTPclient is still sending the data if it has a big body, and the
> server for 404 also closes the connection immediately.
> the immediate connection close yields a broken pipe socketexception in the
> execute httpclient method.
> So depending on timing / http request body size, the result is either the
> server status code (eg 404) or an exception.
> best case would be to check for already returned http response when the
> connection is closed (as the RFC reference in HTTPCLIENT-2093 mentions) - and
> return normally from the execute method?
> attaching a reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
