Jason Smith wrote:
> Thanks, but I think I finally got it. 4th or 5th try.
>
> Anyway, it looks like the InternalInputBuffer.nextRequest() is designed to
> pull data forward to the next buffer. See code excerpt below. But it also
> looks like it makes the assumption that all bytes have been consumed when
> this is called. That isn't happening for me when I'm using chunking. The
> ending '0' is hanging around and ends up on the method name ('POST') of the
> next request that uses the buffer.
>
> Can anyone help shed some light on this? I'm having a hard time figuring out
> who is consuming the body, and if it is their responsibility to eat the last
> '0' in the chunked data stream.
The users list is probably the best place to work this through. If you
reach the conclusion it is a Tomcat issue then create a bugzilla entry,
add a test case and someone will take a look.
Mark
>
> Thanks!
>
> -----Original Message-----
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Monday, April 06, 2009 11:42 AM
> To: Tomcat Developers List
> Subject: Re: Help with a Tomcat bug.
>
> Jason Smith wrote:
>> Trying again. What's the trick to getting past the Apache spam filter????
>
> Generally, use plain text rather than html. Don't use attachments.
>
> Mark
>
>> From: Jason Smith
>> Sent: Monday, April 06, 2009 11:38 AM
>> To: 'dev@tomcat.apache.org'
>> Subject: RE: Help with a Tomcat bug.
>>
>> Trying again. Spam filter seems to hate me.
>>
>> From: Jason Smith
>> Sent: Monday, April 06, 2009 11:08 AM
>> To: 'dev@tomcat.apache.org'
>> Subject: RE: Help with a Tomcat bug.
>>
>> More info. In InternalInputBuffer.nextRequest(), I noticed there is code to
>> pull remaining bytes into the current buffer before switching.
>>
>> /**
>> * End processing of current HTTP request.
>> * Note: All bytes of the current request should have been already
>> * consumed. This method only resets all the pointers so that we are
>> ready
>> * to parse the next HTTP request.
>> */
>> public void nextRequest()
>> throws IOException {
>>
>> // Recycle Request object
>> request.recycle();
>>
>> // Determine the header buffer used for next request
>> byte[] newHeaderBuf = null;
>> if (buf == headerBuffer1) {
>> newHeaderBuf = headerBuffer2;
>> } else {
>> newHeaderBuf = headerBuffer1;
>> }
>>
>> // Copy leftover bytes from buf to newHeaderBuf
>> System.arraycopy(buf, pos, newHeaderBuf, 0, lastValid - pos);
>> if(lastValid-pos > 0)
>> {
>>
>> System.out.println("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
>> System.out.println("'" + new String(Arrays.copyOf(newHeaderBuf,
>> lastValid - pos), "US-ASCII") + "'");
>> }
>>
>> // Swap buffers
>> buf = newHeaderBuf;
>>
>> // Recycle filters
>> for (int i = 0; i <= lastActiveFilter; i++) {
>> activeFilters[i].recycle();
>> }
>>
>> // Reset pointers
>> lastValid = lastValid - pos;
>> pos = 0;
>> lastActiveFilter = -1;
>> parsingHeader = true;
>> swallowInput = true;
>>
>> }
>>
>> I am seeing something like this at one point:
>>
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> 'POST /dh/services/jmap/__exists__ HTTP/1.1
>>
>> But I am also seeing this where this problem is cropping up:
>>
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> '0
>>
>> '
>>
>> Anyone got any ideas on how to fix this? Data from one POST is being
>> carried over to the next POST!!!!!
>>
>> From: Jason Smith
>> Sent: Monday, April 06, 2009 10:16 AM
>> To: 'dev@tomcat.apache.org'
>> Subject: Help with a Tomcat bug.
>>
>> When using .setChunkedStreamingMode(...) from the client, I was getting back
>> an invalid method name in my servlet. Specifically, in the overridden
>> service() method, the request.getMethod() was returning '0\n\nPOST'.
>>
>> I've tracked this all the way into
>> org.apache.coyote.http11.InternalInputBuffer.
>>
>> In .parseRequestLine, the first thing it does is consume leading CRs and
>> LFs. Well, the first line I am getting is '0\n'. So it won't consume that
>> line.
>>
>> The next step parses to the next SPACE character. So it picks up the 0, the
>> CRs and LFs, all the way to the end of POST.
>>
>> The bottom line is that at this point, in this method, the HTTP method name
>> is already messed up.
>>
>> Should this be fixed in this method, or is there a better place?
>>
>> One quick fix:
>>
>> byte chr = 0;
>> do {
>>
>> // Read new bytes if needed
>> if (pos >= lastValid) {
>> if (!fill())
>> throw new EOFException(sm.getString("iib.eof.error"));
>> }
>>
>> chr = buf[pos++];
>>
>> } while ((chr == Constants.CR) || (chr == Constants.LF) || (chr ==
>> '0'));
>>
>>
>> I simply check for the '0' character as well. This is a bit of a hack, but
>> I don't know the code well enough to know if the leading '0' (which I
>> believe is the last line from a previous chunked POST) is supposed to be
>> there or not.
>>
>> Any help would be appreciated.
>>
>> Tomcat 5.5.27, Java 6u13.
>>
>> Jason Smith
>> Software Engineer
>> InfoTrust Group, Inc.
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
