You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Sangjin Lee (JIRA)" <ji...@apache.org> on 2008/02/07 07:45:09 UTC
[jira] Updated: (GERONIMO-3824) ProtocolDecoderException is thrown
if the response does not specify Content-Length but is not chunked
[ https://issues.apache.org/jira/browse/GERONIMO-3824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sangjin Lee updated GERONIMO-3824:
----------------------------------
Attachment: GERONIMO-3824.patch
I have a proposed fix for this.
The idea is to keep looping to add all the remaining contents from the buffer. We do this until the session is closed by the server to terminate the response. The ProtocolDecoder.finishDecode() provides a natural point where one can complete the response when session is getting closed.
I was able to reproduce the problem against a vanilla Tomcat 5.5.26 installation, and verify the fix. Please review the fix, and apply it if you find it acceptable. Also, you may want to propagate this change to the version of AHC in the sandbox based on the mina trunk.
FYI, the mina trunk now has a very nice notion of state-machine classes that express these decoding states succinctly. This problem can be handled by a state named ConsumeToEndOfSessionDecodingState, and that's where I got the hint from...
> ProtocolDecoderException is thrown if the response does not specify Content-Length but is not chunked
> -----------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-3824
> URL: https://issues.apache.org/jira/browse/GERONIMO-3824
> 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(ProtocolCodecFilter.java:164)
> at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
> at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
> at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
> at org.apache.mina.filter.support.SSLHandler.flushScheduledEvents(SSLHandler.java:275)
> at org.apache.mina.filter.SSLFilter.messageReceived(SSLFilter.java:427)
> at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
> at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
> at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
> at org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageReceived(AbstractIoFilterChain.java:499)
> at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
> at org.apache.mina.common.support.AbstractIoFilterChain.fireMessageReceived(AbstractIoFilterChain.java:293)
> at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:228)
> at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:198)
> at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProcessor.java:45)
> at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:485)
> at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:803)
> Caused by: java.lang.StringIndexOutOfBoundsException
> at java.lang.String.substring(String.java:1088)
> at org.apache.ahc.codec.HttpDecoder.decodeStatus(HttpDecoder.java:145)
> at org.apache.ahc.codec.HttpResponseDecoder.processStatus(HttpResponseDecoder.java:276)
> at org.apache.ahc.codec.HttpResponseDecoder.doDecode(HttpResponseDecoder.java:61)
> at org.apache.mina.filter.codec.CumulativeProtocolDecoder.decode(CumulativeProtocolDecoder.java:133)
> at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:157)
> ... 19 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.