tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject RE: Help with a Tomcat issue???
Date Mon, 06 Apr 2009 19:27:52 GMT
Just Tomcat, no proxy.  

And I agree, that isn't the way you'd want to fix it ultimately, but I was experimenting to
find out what worked.  You'd ultimately like to not see the '0' at the beginning of the buffer.
 I found the place where it was getting copied to the beginning of the buffer, but I can't
figure out the logic behind the code.  Too many micro opts (it's fast!).

What did NOT work was simply subverting the copying of the data and setting the buffer length
to 0, as is normally the case.  There are apparently some instances where .nextRequest must
copy the data from one buffer to the next.  I tried.  Things didn't work so well after that...
 :-)  I mentioned one of those in the previous email.  

But again, I am not yet familiar with this part of the Tomcat code.  So I am probably missing
something fairly obvious.

-----Original Message-----
From: Mark Thomas [] 
Sent: Monday, April 06, 2009 1:18 PM
To: Tomcat Users List
Subject: Re: Help with a Tomcat issue???

Jason Smith wrote:

> I have intercepted the socket InputStream (in Http11BaseProtocol) and looked at the data
coming in.  It is what I expect ('POST .').  Yes, let me repeat that, the data coming in from
the socket is good.  I've visually inspected it, and it matches the spec.
It isn't just this request that needs to match the spec - the previous
one has to as well. Otherwise when using keep-alive or pipe-lining you
could see the behaviour you are seeing.

> When I get into the InternalInputBuffer, I am seeing there is data left over at the end
of one stream ('0\n\n') which gets appended to the beginning of the next request because of
the code in .nextRequest().  It almost looks like someone downstream is not consuming the
very last byte in the buffer.
Can you provide source code for the simplest possible client and
simplest possible servlet that demonstrates the issue you are seeing?

> But then why the heck does .nextRequest copy it into the new buffer for the next request?
 This makes no sense to me.
Off the top of my head - I haven't checked the code - pipe-lining?

> Is this a problem with downstream code, which has a responsibility to consume every byte
in the input stream? Or is it bad code in nextRequest(), which really should not be taking
the tail of one request and appending it to the next?  Or is it something else?
Broken client or Tomcat bug would be my guess right now.

> 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.

That almost certainly isn't the way to fix this. That looks to be fixing
 the symptom rather than the root cause.

> Any help would be appreciated.  
> Tomcat 5.5.27, Java 6u13.

Just a double check. Just Tomcat and no httpd/mod_jk/mod_proxy?


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message