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?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
