tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: svn commit: r562022 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml
Date Thu, 02 Aug 2007 12:17:31 GMT
Update: The problem seems to be coming from a global change of AS400 
defines, which unintentionally also hit two ifndefs, which were 
transformed into ifdefs. As a result, we didn't flush any more, so small 
responses were not flushed before we came to the line checking 
sent_bodyct. That way the whole response got replaced by the apache 
error page.

Important: as far as I can see, this should not have introduced a 
problem with Apache 1.3. I didn't yet test, but if there is a problem 
with 401 for Apache 1.3, then there is also another cause we have to 
look for. I'll test but wanted to quickly give an information update.

And: In case we receive an empty body from Tomcat and an error status 
code (>=400), we still throw away the response and let Apache generate a 
new one. More precisely this means, that we throw away all the headers. 
In the 401 case, this way we detected the original problem. I'm not 
sure, if we should really let Apache generate a new local error page 
including headers, if we get an http error code with empty body.

We could also just  pass the response with empty body back to the client.

In fact I was thinking earlier about giving people the chance to decide, 
if they want their error pages coming from apache or from Tomcat. This 
is too complex for a fast fix (as we can see from the 401 example), but 
I think some more thinking after fixing the actual issue would be good.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message