[
https://issues.apache.org/jira/browse/ASYNCWEB-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566788#action_12566788
]
Mike Heath commented on ASYNCWEB-3:
-----------------------------------
This will be difficult to verify if the AsyncWeb codec works properly until we
get AHC using the AsyncWeb codec.
Is the behavior from the Description consistent with all versions of Tomcat
5.5.x? Has this been tried with Tomcat 6? I'm mostly curious as to how best
write a test for this.
> ProtocolDecoderException is thrown if the response does not specify
> Content-Length but is not chunked
> -----------------------------------------------------------------------------------------------------
>
> Key: ASYNCWEB-3
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-3
> Project: Asyncweb
> Issue Type: Bug
> Reporter: Sangjin Lee
> Attachments: ayncweb-3.patch, 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.
