[
https://issues.apache.org/jira/browse/ASYNCWEB-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangjin Lee closed ASYNCWEB-36.
-------------------------------
Resolution: Fixed
Fix Version/s: client-1.0.0
I checked in the fix. There was a bug in the logic that decodes lines in HTTP
responses.
> fail to parse a response line if a CRLF is at the beginning of a buffer
> -----------------------------------------------------------------------
>
> Key: ASYNCWEB-36
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-36
> Project: Asyncweb
> Issue Type: Bug
> Components: Client
> Affects Versions: client-1.0.0
> Reporter: Sangjin Lee
> Assignee: Sangjin Lee
> Fix For: client-1.0.0
>
>
> During the HTTP response decoding, if a CRLF (13 10) falls at the beginning
> of a ByteBuffer that's passed to the decoder, the decoder fails to handle it
> properly. An empty CRLF may appear at the end of the response headers, as
> well as at the end of a chunked response.
> The methods in question are HttpDecoder.decodeLine() and
> HttpDecoder.decodeHeaderLine(). These methods are supposed to return a full
> line, an empty string ("") if the full line is an empty CRLF, or null if the
> buffer contains a partial line so it needs more data. If an empty CRLF falls
> anywhere but the beginning of the buffer, they do return an empty string.
> However, if the empty CRLF comes at the beginning, due to a bug in these
> methods, the methods return null. As a result, the decoder asks for more
> data to decode although the data is there, and the response decoding cannot
> be completed. If the connection gets closed, it results in a "prematurely
> closed" exception. If the connection is kept alive, nothing will happen
> until a timeout happens.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
