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

[Huican Ping]

Thanks Trustin,

Thank you for the quick fix. I will have a try then. 
I will let you know in cast if I still see the problem.

Huican


Trustin Lee wrote:
> 
> 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
> 
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
> 
> 

-- 
View this message in context: http://n2.nabble.com/Netty-has-problem-to-deal-with-the-%22Connection%3A-close%22-message-...-We-cannot-read-the-content.-tp3013392p3018686.html
Sent from the Netty User Group mailing list archive at Nabble.com.