geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick McGuire (JIRA)" <>
Subject [jira] Commented: (GERONIMO-3824) ProtocolDecoderException is thrown if the response does not specify Content-Length but is not chunked
Date Thu, 07 Feb 2008 13:08:08 GMT


Rick McGuire commented on GERONIMO-3824:

Committed revision 619394.  Mina 1.1.5 sandbox version. 
Committed revision 619395.  Mina 2.0 sandbox version. 

> ProtocolDecoderException is thrown if the response does not specify Content-Length but
is not chunked
> -----------------------------------------------------------------------------------------------------
>                 Key: GERONIMO-3824
>                 URL:
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: AsyncHttpClient
>    Affects Versions: 1.x
>            Reporter: Sangjin Lee
>         Attachments: GERONIMO-3824.patch
> I've been testing AHC against different servers, and found an interesting case.
> I configured AHC not to reuse connections (which makes AHC insert "Connection: close"
in its requests).  Then I pointed to a main index.jsp page for a Tomcat 5.5.25 installation.
 What I noticed then is the server does not chunk the content nor sends the Content-Length
header.  It simply closes the connection to terminate.
> This is not a good thing to do, but it is not exactly illegal either, it appears according
to the spec.  In this case, however, the protocol codec gets confused, and throws a StringIndexOutOfBoundsException.
> HttpResponseDecoder makes an explicit assumption that you either chunk the response or
specify the Content-Length header.  Please see HttpResponseCoder.processContent(), and notice
the lack of the else clause.  As a result, HttpResponseCoder transitions to the STATE_CONTENT_READ
state, and thinks it is done with the response (although the content is null).  But HttpResponseDecoder
gets invoked again right away, and that second entry into doDecode() is what throws the exception.
 Please see the following call stack.
> I think at least we should be able to handle a case where the server terminates a response
without specifying the Content-Length header...
> org.apache.mina.filter.codec.ProtocolDecoderException: java.lang.StringIndexOutOfBoundsException
(Hexdump: <omitted>)
> 	at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(
> 	at
> 	at$1100(
> 	at$EntryImpl$1.messageReceived(
> 	at
> 	at org.apache.mina.filter.SSLFilter.messageReceived(
> 	at
> 	at$1100(
> 	at$EntryImpl$1.messageReceived(
> 	at$HeadFilter.messageReceived(
> 	at
> 	at
> 	at
> 	at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(
> 	at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(
> 	at org.apache.mina.transport.socket.nio.SocketIoProcessor$
> 	at
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
> 	at java.util.concurrent.ThreadPoolExecutor$
> 	at
> Caused by: java.lang.StringIndexOutOfBoundsException
> 	at java.lang.String.substring(
> 	at org.apache.ahc.codec.HttpDecoder.decodeStatus(
> 	at org.apache.ahc.codec.HttpResponseDecoder.processStatus(
> 	at org.apache.ahc.codec.HttpResponseDecoder.doDecode(
> 	at org.apache.mina.filter.codec.CumulativeProtocolDecoder.decode(
> 	at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(
> 	... 19 more

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message