[
https://issues.apache.org/jira/browse/HTTPCLIENT-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881026#comment-17881026
]
Patrick Barry commented on HTTPCLIENT-2339:
-------------------------------------------
Thanks Oleg! I looked at DefaultConnectionReuseStrategy and it is not taking
408 response in consideration. After reading Http 1.1 description of what
should happen, should this ticket be a bug so that class incorporates this
use-case?
> Force close on connection when 408 is returned
> ----------------------------------------------
>
> Key: HTTPCLIENT-2339
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2339
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (async)
> Affects Versions: 5.3.1
> Reporter: Patrick Barry
> Priority: Major
>
> Regarding http1.1 requests.... We have a service we are reaching out to, that
> is sending back a 408, but no connection: close.
> According to [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/408]
>
> {noformat}
> The HTTP 408 Request Timeout client error response status code indicates that
> the server would like to shut down this unused connection. A 408 is sent on
> an idle connection by some servers, even without any previous request by the
> client.
> A server should send the Connection: close header field in the response,
> since 408 implies that the server has decided to close the connection rather
> than continue waiting.
> {noformat}
>
> We are using the CloseableHttpAsyncClient with
> PoolingAsyncClientConnectionManager. When we get a 408 and they do not
> specify that connection should be closed, how can we force this? Can it be
> accomplished with an interceptor or is it done by default inside the library?
> The response is actually sending back Connection=keep-alive
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]