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