[
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:12 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
SUBSCRIBE publisher path HTTP/1.1
HOST: publisher host:publisher port
USER-AGENT: OS/version UPnP/1.1 product/version
CALLBACK: <delivery URL>
NT: upnp:event
TIMEOUT: Second-requested subscription duration
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, 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
> 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: [email protected]
For additional commands, e-mail: [email protected]
