Bill Barker wrote:
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.
For reading initial body mod_jk( and mod_ajp) relies on web server providing initial body. For apache we use ap_get_client_block that will return body length if CL is present or in case of chunked encoding. There is however one more thing that needs to be resolved and is pretty important. JK code in Tomcat has no way to figure out if the AJP13_SEND_BODY_CHUNK has failed or not due to client error (for example client closed browser before entire data has been sent). Now I think that the JK connector recycles the current send loop in case there is a 'new' request instead SEND_BODY_CHUNK while the connector was in the send loop, but it does not propagate that to the upper chain, so Tomcat on the next request returns 304 (Not Modified) for the same resource although there was error in previous send. So, in case mod_jk sends AJP13_FORWARD_REQUEST while the Tomcat part was in the SEND_BODY_CHUNK chunk loop the Tomcat part of connector must behave like the connection was closed and then re-established (without closing the socket of course). Regards, Mladen. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
