[
https://issues.apache.org/jira/browse/HTTPCLIENT-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16350236#comment-16350236
]
Petar Petrov commented on HTTPCLIENT-1902:
------------------------------------------
That sounds more than reasonable. Is there a way I can plug in my own
implementation to handle this faulty behavior in a custom manner, so I can
still process the request?
> Handle "HTTP/1.1 000 status code 000" responses
> -----------------------------------------------
>
> Key: HTTPCLIENT-1902
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1902
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 4.5.2, 4.5.5
> Reporter: Petar Petrov
> Assignee: Oleg Kalnichevski
> Priority: Major
> Fix For: 4.5.6, 4.6 Alpha1, 5.0 Beta2
>
> Attachments: canResponseHaveABody.png, doReceiveResponse.png
>
>
> Hi!
> I have a very _funny_ behaviour where the HttpClient seems to wrongly
> interpret the body of an HTTP response as headers, the parsing of which
> eventually leads to a java.net.SocketTimeoutException.
> The underlying cause of this seems to be a a faulty server response, i.e.,
> {noformat}
> HTTP/1.1 000 status code 000{noformat}
> Thank you Apple! /s
>
> I have managed to trace the origin of the problem to the *method
> HttpRequestExecutor#canResponseHaveBody* where, as expected, 000 is not
> considered as a valid status code.
> !canResponseHaveABody.png!
> !doReceiveResponse.png!
> So what happens seems to be that the status line and headers get parsed. The
> 000 is not considered valid and that ends the processing of the response.
> Then the rest of the response (the body) seems to go through the parsing
> procedure again in *DefaultHttpResponseParser#parseHead*. The body is of
> content type application/json. Eventually the following exceptions gets
> thrown after a while:
> {code:java}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)
> at java.net.SocketInputStream.read(SocketInputStream.java:182)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
> at
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
> at
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
> at
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
> at
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
> at
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
> {code}
>
> I'm not really familiar if 000 is even a valid return code. When querying the
> server with some other HTTP tools like Postman, I do get the json response
> with a status code 000.
> Do you guys think this is something that can be fixed in HttpClient or at
> least handled by some sort of an error?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
