tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: svn commit: r359753 - /tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Date Thu, 29 Dec 2005 10:20:43 GMT
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message