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
Hi Mladen,
I don't full yunderstand this fix. From your other mail i though it's a
regression, but the code in this region is the same at least since
1.2.18 (more than a year). So I have the impression, that this is not a
regression. If so, I would prefer to not push 1.2.25 through with very
high speed, i.e. 1.2.24 would still be pretty useful as an update.
Regards,
Rainer
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Wed Aug 1 23:06:18 2007
New Revision: 562022
URL: http://svn.apache.org/viewvc?view=revrev=562022
Log:
Fix the 401 not passed to the client.
Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?view=diffrev=562022r1=562021r2=562022
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Wed Aug 1 23:06:18
2007
@@ -2159,7 +2159,8 @@
if (rc 0) {
/* If tomcat returned no body and the status is not OK,
let apache handle the error code */
-if (!r-sent_bodyct r-status = HTTP_BAD_REQUEST) {
+if (!r-sent_bodyct r-status = HTTP_BAD_REQUEST
+ r-status != HTTP_UNAUTHORIZED) {
jk_log(conf-log, JK_LOG_INFO, No body with status=%d
for worker=%s,
r-status, worker_name);
Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?view=diffrev=562022r1=562021r2=562022
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Wed Aug 1 23:06:18
2007
@@ -2250,7 +2250,8 @@
/* [EMAIL PROTECTED] : under i5/OS sent_bodyct is not set correctly */
/* check for header_only to see if there was a body */
-if (!r-sent_bodyct r-status = HTTP_BAD_REQUEST) {
+if (!r-sent_bodyct r-status = HTTP_BAD_REQUEST
+ r-status != HTTP_UNAUTHORIZED) {
jk_log(xconf-log, JK_LOG_INFO, No body with status=%d
for worker=%s,
r-status, worker_name);
Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?view=diffrev=562022r1=562021r2=562022
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Wed Aug 1
23:06:18 2007
@@ -23,6 +23,16 @@
new documentation project for JK was started.
/p
/section
+section name=Changes between 1.2.24 and 1.2.25
+ br /
+ subsection name=Native
+changelog
+ fix
+Pass the 401 as OK instead sending 401 for authentication. (mturk)
+ /fix
+/changelog
+ /subsection
+/section
section name=Changes between 1.2.23 and 1.2.24
br /
subsection name=Native
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
Rainer Jung wrote: Hi Mladen, I don't full yunderstand this fix. From your other mail i though it's a regression, but the code in this region is the same at least since 1.2.18 (more than a year). So I have the impression, that this is not a regression. You can try 1.2.23 (it works). 1.2.24 doesn't. With patch it works again. I'm not sure if the patch is correct, because it might be that request_rec-sent_bodyct flag is setup differently in 1.2.24 If so, I would prefer to not push 1.2.25 through with very high speed, i.e. 1.2.24 would still be pretty useful as an update. But it doesn't work. You can try 1.2.23 with Tomcat manager app. The browser displays login window for username/password. 1.2.24 displays 401 page from Apache. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
OK, I'll go into it. I think I would propose a slightly different patch, but I'll investigate, why 23 and 24 are different. The reason why I started to pose querstions is, that I found it a little strange to make an exception for exactly one status code. My impression is: the code was supposed to let httpd produce the error page in case we got an error status without any content. But: for a 401 we actually do get a body content from tomcat. So in fact something is wrong with sent_bodycnt. I'll investigate. Regards, Rainer Mladen Turk wrote: Rainer Jung wrote: Hi Mladen, I don't full yunderstand this fix. From your other mail i though it's a regression, but the code in this region is the same at least since 1.2.18 (more than a year). So I have the impression, that this is not a regression. You can try 1.2.23 (it works). 1.2.24 doesn't. With patch it works again. I'm not sure if the patch is correct, because it might be that request_rec-sent_bodyct flag is setup differently in 1.2.24 If so, I would prefer to not push 1.2.25 through with very high speed, i.e. 1.2.24 would still be pretty useful as an update. But it doesn't work. You can try 1.2.23 with Tomcat manager app. The browser displays login window for username/password. 1.2.24 displays 401 page from Apache. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
Rainer Jung wrote: OK, I'll go into it. I think I would propose a slightly different patch, but I'll investigate, why 23 and 24 are different. The reason why I started to pose querstions is, that I found it a little strange to make an exception for exactly one status code. My impression is: the code was supposed to let httpd produce the error page in case we got an error status without any content. But: for a 401 we actually do get a body content from tomcat. So in fact something is wrong with sent_bodycnt. I'll investigate. Probably it is. I personally don't like my patch either, cause it's the kind of 'what other status might be bogus' thing. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
