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

[Huican Ping]

Hello Trustin,


Yes, the last HttpChunk is not received (there is no messasgeReceived
call after the first messageReceive without content inside). Could you
please check that with your test code? I am pretty positive it is a
netty bug.

Our handler is very similar to the one at the example code, and it can
deal with the chunked message as you see all the other messages
instead of 100th are chunked messages.

Thanks
huican


On Wed, Jun 3, 2009 at 3:22 AM, Trustin Lee (via Nabble)
<ml-user+57722-1002982444 at n2.nabble.com> 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 ...
> https://lists.jboss.org/mailman/listinfo/netty-users
> Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
>
> ________________________________
> This email is a reply to your post @
> http://n2.nabble.com/Netty-has-problem-to-deal-with-the-%22Connection%3A-close%22-message-...-We-cannot-read-the-content.-tp3013392p3016931.html
> You can reply by email or by visting the link above.
>
>

-- 
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.-tp3013392p3018639.html
Sent from the Netty User Group mailing list archive at Nabble.com.