Thanks for reporting this. I have changed the code so that
if there is no content only status codes >= 400 are passed
back through apache.
The original patch was made so that when an error occurred at the
Ajp13Processor layer it could propogated back to the browser correctly
instead of a blank page being displayed.
Please test from a CVS build and let me know if this fixes the problem
for you.
Thanks,
Glenn
Aditya wrote:
On 2 Jan 2003 12:58:58 -0000, [EMAIL PROTECTED] said:
glenn 2003/01/02 04:58:58
Modified: jk/native/apache-1.3 mod_jk.c jk/native/apache-2.0
mod_jk.c Log: Make sure http errors are handled by Apache if not
handled by Tomcat
Revision Changes Path 1.34 +6 -1
jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
This fix seems to cause container form-based authentication to have
"problems" - instead of the usual sequence of:
1) GET protected page -> 302 to login page
2) GET login page -> 200 retrieved
3) POST login page -> 302 to protected page
4) GET protected page -> 200 retrieved
The *first* time I try to go to the protected page, instead of (4), I get:
HTTP status 400 (invalid direct reference...)
However, if I then try to get the protected page a *second* time, it works fine...
reverting to a verison of mod_jk that does not include the below fix
doesn't evidence this problem...
Adi
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
