Netty has problem to deal with the "Connection: close" message ... We cannot read the content.

["이희승 (Trustin Lee)"]

Uh, I've just succeeded to reproduce the problem you described by 
myself.  There was a regression in ReplayingDecoder when I fixed 
NETTY-142.  I've just checked in the fix - revision 1316.  Here's the 
filed JIRA issue:

   * https://jira.jboss.org/jira/browse/NETTY-164

Thanks!
Trustin

On 03-Jun-2009 17:21, "이희승 (Trustin Lee) wrote:
> 1) Netty HTTP decoder never closes the connection.  If the connection is
> closed, it's the remote peer (server in your case) or your handler
> implementation. Please let me know if you still think Netty HTTP decoder
> closes the connection.
>
> 2) If there's no way to know the length of the content, Netty transforms
> a non-chunked HTTP message into a chunked HTTP message.
>
> In case of last response, the length of content is only determined when
> the connection is closed. Because it is not safe to buffer the whole
> content until the connection is closed, Netty generates HttpMessage with
> no content first and then HttpChunks.
>
> Your handler should be able to handle this case because any HTTP server
> can send you a chunked HTTP message. Please make sure that you handle
> HttpChunk message properly. The HttpClient example already handles such
> a case, so you could refer to the example.
>
> If you do not like this behavior but just want to limit the content
> length, you can insert HttpChunkAggregator right after
> Http(Request|Response)Decoder in the pipeline. Then you will never
> receive HttpChunk, and an exception will be raised if the content length
> is too large.
>
> Please let me know if HttpChunk is not received at all for the last
> response - it might be a bug then.
>
> HTH,
> Trustin
>
> On 03-Jun-2009 04:02, Huican Ping wrote:
>>
>> More information:
>>
>> The messageReceived() message is same logic as the ones at http example
>> where it does
>> check "respStatus.getCode() == 200&& resp.isChunked() "
>>
>> I noticed for the headers at 100th response:
>> HTTP/1.1 200 OK
>> Server: Apache-Coyote/1.1
>> Content-Type: text/xml;charset=UTF-8
>> Date: Tue, 02 Jun 2009 15:50:12 GMT
>> Connection: close
>>
>> That resp.isChunked() returns true !! While stepping into the code (at
>> DefaultHttpMessage.java isChunked() method), and I dumpped out
>> headers, it
>> has Transfer-Encoding (which I don't know who added it mysteriously).
>> {Connection=[close], Content-Type=[text/xml;charset=UTF-8], Date=[Tue, 02
>> Jun 2009 18:29:59 GMT], Server=[Apache-Coyote/1.1],
>> Transfer-Encoding=[chunked]}
>>
>>
>>
>> Huican Ping wrote:
>>>
>>> I am using the 3.1.0.Beta3.
>>>
>>> That 100th message has no "content-length" header, but has "connection:
>>> close" inside. It is still a valid message.
>>>
>>> Any suggestion or workaround?
>>>
>>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users