"Remy Maucherat" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [EMAIL PROTECTED] wrote: >> Author: billbarker >> Date: Wed Dec 28 23:58:51 2005 >> New Revision: 359753 >> >> URL: http://svn.apache.org/viewcvs?rev=359753&view=rev >> Log: >> Unconditionally return EOS for an attempt to read the body of any request >> that doesn't send CL or TE. >> >> I haven't seen any real objections to the patch (and it can't break a >> working HTTP/1.0 client :). Also, it brings us in like with what Httpd >> does in this case. >> >> Fix for Bug #38030 >> Submitted By: Remy > > I have to do a separate, identical, commit for the HTTP connector people > should be using, then. > > In JK, I don't understand the usage of the "read required" field. It seems > to be set according to: > // Check to see if there should be a body packet coming along > // immediately after > int cl=req.getContentLength(); > if(cl > 0) { > JkInputStream jkIS = ep.getInputStream(); > jkIS.setIsReadRequired(true); > if(!delayInitialRead) { > jkIS.receive(); > } > } > > Does this work with chunking ? >
Without actually checking, mod_jk/mod_proxy_ajp should only send an unrequested initial bodyChunk if the client sends a CL. So if there is no CL, Tomcat will send back GET_BODY_CHUNK message, and act on the response from Httpd/IIS/SunOne. The main purpose of the "read required" field is to clean up if the Servlet fails to actually read the (small) Request body, even though Httpd sent it to Tomcat. Now (like the APR/AJP Connector), Tomcat doesn't attempt to actually read (by default) the unrequested initial bodyChunk until the Servlet asks for it. However, if Httpd sent it, and the Servlet didn't ask for it, Tomcat needs to get it out of the the Socket stream, or bad things are going to happen ;-). > Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
