tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Help with a Tomcat bug.
Date Mon, 06 Apr 2009 17:56:03 GMT
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:markt@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 



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


Mime
View raw message