Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Tue, 22 May 2012 14:09:42 +0000 (UTC)
From: "Michael Pujos (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <925502418.8008.1337695782370.JavaMail.jiratomcat@issues-vm>
In-Reply-To: 
 <1342688647.1626.1309896376664.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Comment Edited] (HTTPCORE-263) IndexOutOfBoundsException
 thrown in AbstractSessionInputBuffer.readLine()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCORE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280966#comment-13280966 ] 

Michael Pujos edited comment on HTTPCORE-263 at 5/22/12 2:08 PM:
-----------------------------------------------------------------

I reread the http spec and CRLF is used t separate lines so forget my comment on it.

Thinking of a situation corresponding to the above schema is harder than I thought. Since this exception happens when parsing the request header line (parseHead()), it cannot happen 
on the initial client request. So it happens when the AbstractSessionInputubbfer is used to handle a subsequent request from the same client using the same connection.

App handle UPnp specific requests with SUBSCRIBE, UNSUBSCRIBE, NOTIFY methods mixed with regular GET and POST methods, possibly handled by the same HttpService instance thus sharing the AbstractSessionInputBuffer.
SUBSCRIBE AND UNSUBSCIRBE do not have a body and the spec says: "No body for request with method SUBSCRIBE, but note that the message MUST have a blank line following the last HTTP header
field"

I think this situation may happen with malformed successive requests although I cannot think of an example.

A SUBSCRIBE message look like this


      was (Author: bubbleguuum):
    I reread the http spec and CRLF is used t separate lines so forget my comment on it.

Thinking of a situation corresponding to the above schema is harder than I thought. Since this exception happens when parsing the request header line (parseHead()), it cannot happen 
on the initial client request. So it happens when the AbstractSessionInputubbfer is used to handle a subsequent request from the same client using the same connection.

App handle UPnp specific requests with SUBSCRIBE, UNSUBSCRIBE, NOTIFY methods mixed with regular GET and POST methods
SUBSCRIBE AND UNSUBSCIRBE do not have a body and the spec says: "No body for request with method SUBSCRIBE, but note that the message MUST have a blank line following the last HTTP header
field"

I think this situation may happen with malformed successive requests although I cannot think of an example


> IndexOutOfBoundsException thrown in AbstractSessionInputBuffer.readLine()
> -------------------------------------------------------------------------
>
>                 Key: HTTPCORE-263
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-263
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore
>    Affects Versions: 4.1.1
>         Environment: reported on Android  2.3.3 using repackaged httpcore 4.1.1, optimized and obfuscated with Proguard
>            Reporter: Michael Pujos
>            Priority: Minor
>             Fix For: 4.2.1
>
>
> I've got the exception below reported in my Android app using (repackaged) httpcore 4.1.1:
> java.lang.IndexOutOfBoundsException: off: 1088 len: -1 b.length: 8192
> 	at org.apache.http.util.CharArrayBuffer.append(SourceFile:185)
> 	at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(SourceFile:251)
> 	at org.apache.http.impl.io.HttpRequestParser.parseHead(SourceFile:90)
> 	at org.apache.http.impl.io.AbstractMessageParser.parseHead(SourceFile:252)
>                                                                  parse
> 	at org.apache.http.impl.AbstractHttpServerConnection.receiveRequestHeader(SourceFile:242)
> 	at org.apache.http.protocol.HttpService.handleRequest(SourceFile:238)
> 	at org.teleal.cling.transport.impl.apache.HttpServerConnectionUpnpStream.run(SourceFile:116)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1088)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:581)
> 	at java.lang.Thread.run(Thread.java:1019)
> It seems to be very rare. Stack trace line number (185) in AbstractSessionInputBuffer doesn't exaclty match the exact line number of the offending append() call (probably due to Proguard).
> However,  there are 2 append() calls in readLine(), and it looks like one of them is called with len = -1, triggering the IndexOutOfBoundsException in append()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org