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

[Huican Ping]

Sorry Trustin,

I synced to Rev 1316, and got the same result: the last response's content
chunk was not received, e.g, no messageReceived() called second time.

For the 100th response like below (FYI, the body is NOT wrapped with chunked
byte size, I don't know whether it will cause problem since netty THINKs
this response is chunked encoding message but as you see the body is not
wrapped the content size as normally chunked message does):
	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
	
	<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns1:echo
xmlns:ns1="http://example1.org/example1"><Text>echo:
hello</Text></ns1:echo></soapenv:Body></soapenv:Envelope>


In my httpResponseHandler, the code goes into messageReceived() first time,
and the check "respStatus.getCode() == 200 && resp.isChunked()" is true,
then I just mark "readingChunk = true". Later on, there is no 2nd
messageReceived() call. 


The messageReceived method is same as the HttpResponseHandler example
logically, such as:
if ( !readingChunks )
{
	HttpResponse resp = (HttpResponse) event.getMessage();

	...
	
	if (respStatus.getCode() == 200 && resp.isChunked() )
	{
		// First one is always 0 length, just set readingCHunks to true
		readingChunks = true;
		....
	}
	else 
	{	
		// Here is the case of - content-length < 'maxChunkSize'
		// we need get the content and send resp.
		final ChannelBuffer buffer = resp.getContent();
		....
	}
}
// for the left chunks
else 
{
	HttpChunk chunk = (HttpChunk) event.getMessage();
	...
	
	if (chunk.isLast())
	{
		readingChunks = false;
		// Send the response to the workflow
		....
	}
}


Huican Ping wrote:
> 
> 
> 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.-tp3013392p3019015.html
Sent from the Netty User Group mailing list archive at Nabble.com.