[jira] Resolved: (ASYNCWEB-5) asyncweb build is broken
[ https://issues.apache.org/jira/browse/ASYNCWEB-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved ASYNCWEB-5. - Resolution: Fixed Committed revision 633433. Thanks Sangjin. > asyncweb build is broken > > > Key: ASYNCWEB-5 > URL: https://issues.apache.org/jira/browse/ASYNCWEB-5 > Project: Asyncweb > Issue Type: Bug >Reporter: Sangjin Lee >Priority: Blocker > Attachments: ASYNCWEB-5.patch > > > The asyncweb build is broken at AsyncHttpClientTest. Also, there is a broken > unit test once you get past the build breakage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ASYNCWEB-3) ProtocolDecoderException is thrown if the response does not specify Content-Length but is not chunked
[ https://issues.apache.org/jira/browse/ASYNCWEB-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire updated ASYNCWEB-3: Attachment: ayncweb-3.patch This is a merge of the original Geronimo sandbox changes into the asyncweb ahc client. > 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: ) > 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
[jira] Moved: (ASYNCWEB-3) ProtocolDecoderException is thrown if the response does not specify Content-Length but is not chunked
[ https://issues.apache.org/jira/browse/ASYNCWEB-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire moved GERONIMO-3824 to ASYNCWEB-3: --- Security: (was: public) Component/s: (was: AsyncHttpClient) Affects Version/s: (was: 1.x) Key: ASYNCWEB-3 (was: GERONIMO-3824) Project: Asyncweb (was: Geronimo) > 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: 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: ) > 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 >
