[
https://issues.apache.org/jira/browse/ASYNCWEB-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566800#action_12566800
]
Sangjin Lee commented on ASYNCWEB-3:
------------------------------------
I think Tomcat 6 acts differently. Even with connection close it seems to send
the content-length header.
I observed this behavior with 5.5.25 and 5.5.26. I downloaded a vanilla Tomcat
5.5.26, started it, and hit the index jsp with AHC (make sure you don't reuse
connections).
Since we're using an embedded Tomcat 6 server to test this, I'm not exactly
sure how we can best emulate this situation. Perhaps at some point we want to
have an embedded asyncweb server to drive 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.
