svn commit: r562025 - in /tomcat/connectors/trunk/jk/native: common/jk_version.h iis/installer/isapi-redirector-win32-msi.ism iis/isapi_redirect.rc
Author: mturk Date: Wed Aug 1 23:10:29 2007 New Revision: 562025 URL: http://svn.apache.org/viewvc?view=revrev=562025 Log: Increment version to 1.2.25-dev Modified: tomcat/connectors/trunk/jk/native/common/jk_version.h tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc Modified: tomcat/connectors/trunk/jk/native/common/jk_version.h URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_version.h?view=diffrev=562025r1=562024r2=562025 == --- tomcat/connectors/trunk/jk/native/common/jk_version.h (original) +++ tomcat/connectors/trunk/jk/native/common/jk_version.h Wed Aug 1 23:10:29 2007 @@ -26,14 +26,14 @@ /** START OF AREA TO MODIFY BEFORE RELEASING */ #define JK_VERMAJOR 1 #define JK_VERMINOR 2 -#define JK_VERFIX 24 -#define JK_VERSTRING1.2.24 +#define JK_VERFIX 25 +#define JK_VERSTRING1.2.25 /* Beta number */ #define JK_VERBETA 0 #define JK_BETASTRING 0 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ -#define JK_VERISRELEASE 1 +#define JK_VERISRELEASE 0 #define JK_VERRC0 #define JK_RCSTRING 0 Modified: tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism?view=diffrev=562025r1=562024r2=562025 == --- tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism (original) +++ tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism Wed Aug 1 23:10:29 2007 @@ -3409,7 +3409,7 @@ rowtdProductID/tdtdnone/tdtd//row rowtdProductLanguage/tdtd1033/tdtd//row rowtdProductName/tdtdTomcat Isapi Redirector/tdtd//row - rowtdProductVersion/tdtd1.2.24/tdtd//row + rowtdProductVersion/tdtd1.2.25/tdtd//row rowtdProgressType0/tdtdinstall/tdtd//row rowtdProgressType1/tdtdInstalling/tdtd//row rowtdProgressType2/tdtdinstalled/tdtd//row Modified: tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc?view=diffrev=562025r1=562024r2=562025 == --- tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc (original) +++ tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc Wed Aug 1 23:10:29 2007 @@ -14,13 +14,13 @@ specific language governing permissions and \ limitations under the License. -#define JK_VERSION_STR 1.2.24 +#define JK_VERSION_STR 1.2.25 #define JK_DLL_BASENAME isapi_redirect- JK_VERSION_STR 1 VERSIONINFO - FILEVERSION 1,2,24,0 - PRODUCTVERSION 1,2,24,0 + FILEVERSION 1,2,25,0 + PRODUCTVERSION 1,2,25,0 FILEFLAGSMASK 0x3fL #if defined(_DEBUG) FILEFLAGS 0x01L - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Serious regression in JK 1.2.24
Hi, We have a problem with 1.2.24 that luckily is not security leak, but it is security related. The problem is that 401 from Tomcat without body (a standard HTTP_UNAUTHORIZED) is treated as 401, meaning that Apache is returning 401 page instead passing 401 to the client. I already patched the SVN. Can we roll 1.2.25? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serious regression in JK 1.2.24
Hi, OK with me. I've one outstanding patch related to fail on status. I think Ben short is testing today. I wrote mails about it to the user list and the patch is not committed yet. It's http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch (in short: fail on status has to be moved to a place a little earlier, because at the moment headers are set before fail on status. So if we do a retry and get different headers back, we produce an answer with an undefined mix of headers. In the users case we set Content-Length from the failure response, and the retry on another node succeeded with a chunked encoding ...) Also there is one outstanding fix concerning nsapi on netware (which now has an unneeded dependency on shm). We could review all changes since 1.2.24 (that's not much) and then skip the quality check phase, instead directly roll an oficial test/vote tarball. Would tomorrow be OK for that? Regards, Rainer Mladen Turk wrote: Hi, We have a problem with 1.2.24 that luckily is not security leak, but it is security related. The problem is that 401 from Tomcat without body (a standard HTTP_UNAUTHORIZED) is treated as 401, meaning that Apache is returning 401 page instead passing 401 to the client. I already patched the SVN. Can we roll 1.2.25? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43009] - Reported exception is not original cause of problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43009. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43009 --- Additional Comments From [EMAIL PROTECTED] 2007-08-02 01:52 --- In the end, I think there isn't a bug here after all so this issue could be safely ignored. war.delete(); is called earlier as the first statement in the method, so if it is going to throw a SecurityException, it will already have done so. The actual problem I was investigating turned out to be elsewhere (will submit that separately). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
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]
DO NOT REPLY [Bug 43013] New: - No mention of limitation regarding deployment with multi-level context paths (e.g. /123/456)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43013. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43013 Summary: No mention of limitation regarding deployment with multi-level context paths (e.g. /123/456) Product: Tomcat 5 Version: 5.5.23 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I understand correctly, the manager app doesn't support deployment with multi-level context paths e.g. path=/123/456. I couldn't see any mention of this limitation in the docs. Would be useful if it was mentioned there. Also, if trying to do this, the deployment fails but with no explanation. It should be simple to add a test for multi-level paths and exit with an appropriate error message, e.g. Inserting after this block from org.apache.catalina.manager.ManagerServlet // Validate the requested context path if ((path == null) || path.length() == 0 || !path.startsWith(/)) { writer.println(sm.getString(managerServlet.invalidPath, path)); return; } the following code at line 588: if (path.lastIndexOf(/) 0) { writer.println(sm.getString(managerServlet.unsupportedPath, path)); return; } Adding appropriate messages to properties files of course. It would be even better if the manager could deploy apps using such a context path but that would be an enhancement so I'll request that separately. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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]
DO NOT REPLY [Bug 43014] New: - Enable manager to deploy apps with multi-level paths, e.g. /123/456
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43014. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43014 Summary: Enable manager to deploy apps with multi-level paths, e.g. /123/456 Product: Tomcat 5 Version: 5.5.23 Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I understand correctly, it can't do this at the moment, ref: http://www.nabble.com/Using-manager-to-deploy-with-path%3D%22-123-456-789%22-t4200949.html Would be good if it could. I'm thinking that an administrator would be able to define a location outside of appBase where war's for such apps could be expanded, e.g. catalina_base/outsideAppBase The manager on recognising such a contex-path could then expand the war there (in a subdir according to the context-path specified, and create an appropriate context xml file to go into catalina-base/conf/Engine/host/ Interested to hear what you think, and if you forsee any problems with this approach. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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]
DO NOT REPLY [Bug 43013] - No mention of limitation regarding deployment with multi-level context paths (e.g. /123/456)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43013. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43013 --- Additional Comments From [EMAIL PROTECTED] 2007-08-02 04:09 --- *** Bug 43014 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562085 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
Author: rjung Date: Thu Aug 2 04:57:29 2007 New Revision: 562085 URL: http://svn.apache.org/viewvc?view=revrev=562085 Log: Partially undo r530674: Chanhing the AS400 ifdefs also hit two ifndefs instead of only ifdefs. As a consequence, we didn't flush any more. Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c 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=562085r1=562084r2=562085 == --- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original) +++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Thu Aug 2 04:57:29 2007 @@ -375,7 +375,7 @@ static void JK_METHOD ws_flush(jk_ws_service_t *s) { -#if defined(AS400) !defined(AS400_UTF8) +#ifndef AS400 if (s s-ws_private) { apache_private_data_t *p = s-ws_private; ap_rflush(p-r); @@ -423,7 +423,7 @@ } } if (p-r-header_only) { -#if defined(AS400) !defined(AS400_UTF8) +#ifndef AS400 ap_rflush(p-r); #endif return JK_TRUE; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.14
Remy Maucherat wrote: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.14/ According to the release process, the 6.0.14 tag is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable Ok, so far this build seems stable. Any other votes ? Rémy - 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]
Re: Juli/Logging
Rainer Jung wrote: That's why it would be nice if someone took the burden of writing a better log formatter for j.u.l. Got it. Yea, that format is certainly grep unfriendly. Looks like Harmony has a formatter we could copy from and fix to not add the new line. http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java Yes, that could be a good starting point (although that implementation does not care about localization). It might be better to use log4j code as a starting point as it already has the pattern processing code. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562090 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c
Author: rjung Date: Thu Aug 2 05:10:48 2007 New Revision: 562090 URL: http://svn.apache.org/viewvc?view=revrev=562090 Log: Revert the quickfix r562022. It looks like we found the real problem with r562085. Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c 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=562090r1=562089r2=562090 == --- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original) +++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Thu Aug 2 05:10:48 2007 @@ -2159,8 +2159,7 @@ 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 - r-status != HTTP_UNAUTHORIZED) { +if (!r-sent_bodyct r-status = HTTP_BAD_REQUEST) { 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=562090r1=562089r2=562090 == --- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original) +++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Thu Aug 2 05:10:48 2007 @@ -2250,8 +2250,7 @@ /* [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 - r-status != HTTP_UNAUTHORIZED) { +if (!r-sent_bodyct r-status = HTTP_BAD_REQUEST) { jk_log(xconf-log, JK_LOG_INFO, No body with status=%d for worker=%s, r-status, worker_name); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r562090 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c
[EMAIL PROTECTED] wrote: Author: rjung Date: Thu Aug 2 05:10:48 2007 New Revision: 562090 URL: http://svn.apache.org/viewvc?view=revrev=562090 Log: Revert the quickfix r562022. It looks like we found the real problem with r562085. Perfect. The fix makes login working once again. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562109 - in /tomcat/site/trunk: docs/download-connectors.html xdocs/download-connectors.xml
Author: rjung Date: Thu Aug 2 06:43:54 2007 New Revision: 562109 URL: http://svn.apache.org/viewvc?view=revrev=562109 Log: Withdraw JK 1.2.24 relase. Revert download page to 1.2.23 and add a warning concerning the withdrawal. Modified: tomcat/site/trunk/docs/download-connectors.html tomcat/site/trunk/xdocs/download-connectors.xml Modified: tomcat/site/trunk/docs/download-connectors.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/download-connectors.html?view=diffrev=562109r1=562108r2=562109 == --- tomcat/site/trunk/docs/download-connectors.html (original) +++ tomcat/site/trunk/docs/download-connectors.html Thu Aug 2 06:43:54 2007 @@ -225,7 +225,7 @@ li class=group div class=links span class=labelJK 1.2 (b -a href=security-jk.htmlWARNING: Important vulnerabilities in previous versions/a +a href=security-jk.htmlWARNING: Release 1.2.24 has been withdrawn./a /b) /span /div @@ -236,18 +236,18 @@ /div ul li class=download -a href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.tar.gzJK 1.2.24 Source Release tar.gz/a (e.g. Unix, Linux, Mac OS) +a href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.tar.gzJK 1.2.23 Source Release tar.gz/a (e.g. Unix, Linux, Mac OS) ul class=attributes li -span class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.tar.gz.asc;pgp/a]/span +span class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.tar.gz.asc;pgp/a]/span /li /ul /li li class=download -a href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.zipJK 1.2.24 Source Release zip/a (e.g. Windows) +a href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.zipJK 1.2.23 Source Release zip/a (e.g. Windows) ul class=attributes li -span class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.zip.asc;pgp/a]/span +span class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.zip.asc;pgp/a]/span /li /ul /li Modified: tomcat/site/trunk/xdocs/download-connectors.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/download-connectors.xml?view=diffrev=562109r1=562108r2=562109 == --- tomcat/site/trunk/xdocs/download-connectors.xml (original) +++ tomcat/site/trunk/xdocs/download-connectors.xml Thu Aug 2 06:43:54 2007 @@ -26,17 +26,17 @@ /div ul class=downloads li class=group -div class=linksspan class=labelJK 1.2 (ba href=security-jk.htmlWARNING: Important vulnerabilities in previous versions/a/b) +div class=linksspan class=labelJK 1.2 (ba href=security-jk.htmlWARNING: Release 1.2.24 has been withdrawn./a/b) /span/div ulli class=group div class=linksspan class=labelSource (please choose the correct format for your platform)/span/div -ulli class=downloada href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.tar.gzJK 1.2.24 Source Release tar.gz/a (e.g. Unix, Linux, Mac OS) -ul class=attributeslispan class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.tar.gz.asc;pgp/a]/span +ulli class=downloada href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.tar.gzJK 1.2.23 Source Release tar.gz/a (e.g. Unix, Linux, Mac OS) +ul class=attributeslispan class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.tar.gz.asc;pgp/a]/span /li /ul /li -li class=downloada href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.zipJK 1.2.24 Source Release zip/a (e.g. Windows) -ul class=attributeslispan class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.24/tomcat-connectors-1.2.24-src.zip.asc;pgp/a]/span +li class=downloada href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.zipJK 1.2.23 Source Release zip/a (e.g. Windows) +ul class=attributeslispan class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.23/tomcat-connectors-1.2.23-src.zip.asc;pgp/a]/span /li /ul /li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.24 withdrawal?
I agree. Remove 1.2.24 and include all the patches. Let's roll that ASAP. Regards, Mladen. Rainer Jung wrote: I think the problem with JK 1.2.24 is big enough to release soon. I would also suggest to officially withdraw 1.2.24 from the download and web site (with a comment indicating the problem) so that people will not run into more complex problems related to the missing flush. Although we've got no indication, that there will be a security problem, the missing flushing can lead to undefined behaviour. Users needed to wait for a post 1.2.23 update for 2.5 months, so 1-2 more weeks will be OK. Additionally the question is: should we include other fixes or strictly only 1.2.24 + this fix. If we remove 1.2.24 I think the other fixes listed below will be safe. I would propose to include them and run through the usual Quality check + release cycle, we've done a couple of times for JK. r560736 (fuankg): additional defines in jk_globalh. if __GNUC__ is defined for WIN32 or Netware. This should enable gcc builds on these platforms. Looks like very low risk, because until now we don't support building with gcc on these platforms, so the change looks like it can't break anything. r560739 (fuankg): Change in Netware Makefile for Apache 1.3. I think Günter knows best, if this should be released. r560823 (rjung): changed pid_t print format detection for Solaris. Tested with gcc and cc for 32 Bit and 64 Bit build on Solaris Sparc. Not tested for Solaris x86, but until now I think we do not actively support this. r560831 (rjung): Fix nsapi crash with debug log during startup. Very local change, low risk. r562085 (rjung): Fix 401 problem. That's the one we definitely need. Outstanding changes: fail on status -- http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch Improve nsapi shut down --- Index: netscape/jk_nsapi_plugin.c === --- netscape/jk_nsapi_plugin.c (revision 562051) +++ netscape/jk_nsapi_plugin.c (working copy) @@ -320,14 +320,15 @@ uri_worker_map_free(uw_map, logger); } +if (init_map) { +jk_map_free(init_map); +} + +jk_shm_close(); wc_close(logger); if (logger) { jk_close_file_logger(logger); } - -if (init_map) { -jk_map_free(init_map); -} } Improve nsapi returning correctly when errors occur --- Index: netscape/jk_nsapi_plugin.c === --- netscape/jk_nsapi_plugin.c (revision 562051) +++ netscape/jk_nsapi_plugin.c (working copy) @@ -382,10 +382,14 @@ } else { if ((result == JK_CLIENT_ERROR) (is_error == JK_HTTP_OK)) { +rc = REQ_EXIT; +protocol_status(sn, rq, is_error, NULL); jk_log(logger, JK_LOG_INFO, service() failed because client aborted connection); } else { +rc = REQ_ABORTED; +protocol_status(sn, rq, is_error, NULL); jk_log(logger, JK_LOG_ERROR, service() failed with http error %d, is_error); } nsapi and shm -- For Netware nsapi now has a build dependency on shm although it doesn't use it. More generally, we need to check which way we should use shm for nsapi on which platform. I think the nsapi and general platforms considerations should not be done before 1.2.25, but everything else looks OK to me. Regards, Rainer Mladen Turk wrote: [EMAIL PROTECTED] wrote: Author: rjung Date: Thu Aug 2 05:10:48 2007 New Revision: 562090 URL: http://svn.apache.org/viewvc?view=revrev=562090 Log: Revert the quickfix r562022. It looks like we found the real problem with r562085. Perfect. The fix makes login working once again. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk 1.2.24 withdrawal?
I think the problem with JK 1.2.24 is big enough to release soon. I would also suggest to officially withdraw 1.2.24 from the download and web site (with a comment indicating the problem) so that people will not run into more complex problems related to the missing flush. Although we've got no indication, that there will be a security problem, the missing flushing can lead to undefined behaviour. Users needed to wait for a post 1.2.23 update for 2.5 months, so 1-2 more weeks will be OK. Additionally the question is: should we include other fixes or strictly only 1.2.24 + this fix. If we remove 1.2.24 I think the other fixes listed below will be safe. I would propose to include them and run through the usual Quality check + release cycle, we've done a couple of times for JK. r560736 (fuankg): additional defines in jk_globalh. if __GNUC__ is defined for WIN32 or Netware. This should enable gcc builds on these platforms. Looks like very low risk, because until now we don't support building with gcc on these platforms, so the change looks like it can't break anything. r560739 (fuankg): Change in Netware Makefile for Apache 1.3. I think Günter knows best, if this should be released. r560823 (rjung): changed pid_t print format detection for Solaris. Tested with gcc and cc for 32 Bit and 64 Bit build on Solaris Sparc. Not tested for Solaris x86, but until now I think we do not actively support this. r560831 (rjung): Fix nsapi crash with debug log during startup. Very local change, low risk. r562085 (rjung): Fix 401 problem. That's the one we definitely need. Outstanding changes: fail on status -- http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch Improve nsapi shut down --- Index: netscape/jk_nsapi_plugin.c === --- netscape/jk_nsapi_plugin.c (revision 562051) +++ netscape/jk_nsapi_plugin.c (working copy) @@ -320,14 +320,15 @@ uri_worker_map_free(uw_map, logger); } +if (init_map) { +jk_map_free(init_map); +} + +jk_shm_close(); wc_close(logger); if (logger) { jk_close_file_logger(logger); } - -if (init_map) { -jk_map_free(init_map); -} } Improve nsapi returning correctly when errors occur --- Index: netscape/jk_nsapi_plugin.c === --- netscape/jk_nsapi_plugin.c (revision 562051) +++ netscape/jk_nsapi_plugin.c (working copy) @@ -382,10 +382,14 @@ } else { if ((result == JK_CLIENT_ERROR) (is_error == JK_HTTP_OK)) { +rc = REQ_EXIT; +protocol_status(sn, rq, is_error, NULL); jk_log(logger, JK_LOG_INFO, service() failed because client aborted connection); } else { +rc = REQ_ABORTED; +protocol_status(sn, rq, is_error, NULL); jk_log(logger, JK_LOG_ERROR, service() failed with http error %d, is_error); } nsapi and shm -- For Netware nsapi now has a build dependency on shm although it doesn't use it. More generally, we need to check which way we should use shm for nsapi on which platform. I think the nsapi and general platforms considerations should not be done before 1.2.25, but everything else looks OK to me. Regards, Rainer Mladen Turk wrote: [EMAIL PROTECTED] wrote: Author: rjung Date: Thu Aug 2 05:10:48 2007 New Revision: 562090 URL: http://svn.apache.org/viewvc?view=revrev=562090 Log: Revert the quickfix r562022. It looks like we found the real problem with r562085. Perfect. The fix makes login working once again. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.24 withdrawal?
I withdrew the release from the server: - removed 1.2.24 source and binaries from www.apache.org/dist/... - put back 1.2.23 source and binaries from archive - reverted the download page and added a warning - added a withdrawal note to the index and news page in the live online docs. It will take the usual time to sync to www.a.o/tomcat.a.o and the mirrors. I'm going to send a note to the users and dev list. Regards, Rainer Mladen Turk wrote: I agree. Remove 1.2.24 and include all the patches. Let's roll that ASAP. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Withdrawal of Apache Tomcat JK 1.2.24 Web Server Connectors
The Apache Tomcat team needs to withdraw release 1.2.24 of the Apache Tomcat Connectors. The release contains a bug that prevents the correct flushing of parts of responses from the web server to the client. This might result in unpredicted communication behaviour. We therefore have removed the source and binary distributions from the origin server. A fix for the problem has already been committed. We expect release of version 1.2.25 in sometime next week. We apologise for any inconvenience, -- The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562127 - /tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c
Author: rjung Date: Thu Aug 2 07:39:04 2007 New Revision: 562127 URL: http://svn.apache.org/viewvc?view=revrev=562127 Log: Allow missing shm_file attribute for nsapi plugin on WIN32 and Netware platforms. Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c?view=diffrev=562127r1=562126r2=562127 == --- tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c (original) +++ tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Thu Aug 2 07:39:04 2007 @@ -231,6 +231,7 @@ char *log_level_str = pblock_findval(JK_LOG_LEVEL_TAG, pb); char *log_file = pblock_findval(JK_LOG_FILE_TAG, pb); char *shm_file = pblock_findval(JK_SHM_FILE_TAG, pb); +char *shm_file_safe = ; char *reject_unsafe = pblock_findval(REJECT_UNSAFE_TAG, pb); int rc = REQ_ABORTED; @@ -249,11 +250,16 @@ return rc; } -if (!shm_file) { +if (shm_file) { +shm_file_safe = shm_file; +} +#if !defined(WIN32) !defined(NETWARE) +else { fprintf(stderr, Missing attribute %s in magnus.conf (jk_init) - aborting!\n, JK_SHM_FILE_TAG); return rc; } +#endif fprintf(stderr, In jk_init.\n Worker file = %s.\n Log level = %s.\n Log File = %s\n SHM File = %s\n, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562129 - /tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c
Author: rjung Date: Thu Aug 2 07:43:08 2007 New Revision: 562129 URL: http://svn.apache.org/viewvc?view=revrev=562129 Log: Add correct plugin return when service ends with an error. Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c?view=diffrev=562129r1=562128r2=562129 == --- tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c (original) +++ tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Thu Aug 2 07:43:08 2007 @@ -387,11 +387,14 @@ service() returned OK); } else { +protocol_status(sn, rq, is_error, NULL); if ((result == JK_CLIENT_ERROR) (is_error == JK_HTTP_OK)) { +rc = REQ_EXIT; jk_log(logger, JK_LOG_INFO, service() failed because client aborted connection); } else { +rc = REQ_ABORTED; jk_log(logger, JK_LOG_ERROR, service() failed with http error %d, is_error); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562131 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
Author: rjung Date: Thu Aug 2 07:47:00 2007 New Revision: 562131 URL: http://svn.apache.org/viewvc?view=revrev=562131 Log: Move fail on status a little down the protocol stack, so that we haven't yet returned the headers. Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c?view=diffrev=562131r1=562130r2=562131 == --- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c (original) +++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Thu Aug 2 07:47:00 2007 @@ -1423,6 +1423,18 @@ return (JK_TRUE); } + +static int is_http_status_fail(ajp_worker_t *w, int status) +{ +unsigned int i; +for (i = 0; i w-http_status_fail_num; i++) { +if (w-http_status_fail[i] == status) +return 1; +} +return 0; +} + + /* * What to do with incoming data (dispatcher) */ @@ -1445,13 +1457,17 @@ JK_TRACE_EXIT(l); return JK_AJP13_ERROR; } +r-http_response_status = res.status; +if (is_http_status_fail(ae-worker, res.status)) { +JK_TRACE_EXIT(l); +return JK_STATUS_ERROR; +} r-start_response(r, res.status, res.msg, (const char *const *)res.header_names, (const char *const *)res.header_values, res.num_headers); if (r-flush r-flush_header) r-flush(r); -r-http_response_status = res.status; } return JK_AJP13_SEND_HEADERS; @@ -1564,17 +1580,6 @@ return JK_AJP13_NO_RESPONSE; } -static int is_http_status_fail(ajp_worker_t *w, int status) -{ -unsigned int i; -for (i = 0; i w-http_status_fail_num; i++) { -if (w-http_status_fail[i] == status) -return 1; -} -return 0; -} - - /* * get replies from Tomcat via Ajp13/Ajp14 * We will know only at read time if the remote host closed @@ -1733,11 +1738,11 @@ return JK_TRUE; } else if (JK_AJP13_SEND_HEADERS == rc) { -if (is_http_status_fail(p-worker, s-http_response_status)) { -JK_TRACE_EXIT(l); -return JK_STATUS_ERROR; -} headeratclient = JK_TRUE; +} +else if (JK_STATUS_ERROR == rc) { +JK_TRACE_EXIT(l); +return JK_STATUS_ERROR; } else if (JK_AJP13_HAS_RESPONSE == rc) { /* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562130 - /tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c
Author: rjung Date: Thu Aug 2 07:45:24 2007 New Revision: 562130 URL: http://svn.apache.org/viewvc?view=revrev=562130 Log: Fix shm shutdown behaviour of nsapi plugin. Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c?view=diffrev=562130r1=562129r2=562130 == --- tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c (original) +++ tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Thu Aug 2 07:45:24 2007 @@ -326,13 +326,14 @@ uri_worker_map_free(uw_map, logger); } +if (init_map) { +jk_map_free(init_map); +} + +jk_shm_close(); wc_close(logger); if (logger) { jk_close_file_logger(logger); -} - -if (init_map) { -jk_map_free(init_map); } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
I think something is missing - DirectJDKLog is looking for a JdkLoggerFormatter that would do the trick. I may have forgot to add it, I have it on my machine ( I hate too the default format ). There's also a config override allowing default properties to be loaded from a different location. Costin On 8/2/07, Remy Maucherat [EMAIL PROTECTED] wrote: Rainer Jung wrote: That's why it would be nice if someone took the burden of writing a better log formatter for j.u.l. Got it. Yea, that format is certainly grep unfriendly. Looks like Harmony has a formatter we could copy from and fix to not add the new line. http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java Yes, that could be a good starting point (although that implementation does not care about localization). It might be better to use log4j code as a starting point as it already has the pattern processing code. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
Costin Manolache wrote: I think something is missing - DirectJDKLog is looking for a JdkLoggerFormatter that would do the trick. I may have forgot to add it, I have it on my machine ( I hate too the default format ). There's also a config override allowing default properties to be loaded from a different location. I don't think I removed those two classes, so feel free to add them. You don't need to hardcode configuration, the LogManager that replaces the default one supports a lot of stuff. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562174 - in /tomcat/connectors/trunk/jk/native/common: jk_status.c jk_uri_worker_map.c
Author: jim Date: Thu Aug 2 09:28:29 2007 New Revision: 562174 URL: http://svn.apache.org/viewvc?view=revrev=562174 Log: These are local functions; ensure we don't clobber things and handle compiler warnings about prototypes. Modified: tomcat/connectors/trunk/jk/native/common/jk_status.c tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c Modified: tomcat/connectors/trunk/jk/native/common/jk_status.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_status.c?view=diffrev=562174r1=562173r2=562174 == --- tomcat/connectors/trunk/jk/native/common/jk_status.c (original) +++ tomcat/connectors/trunk/jk/native/common/jk_status.c Thu Aug 2 09:28:29 2007 @@ -733,7 +733,7 @@ return def; } -const char *status_cmd_text(int cmd) +static const char *status_cmd_text(int cmd) { return cmd_type[cmd]; } @@ -759,7 +759,7 @@ return JK_STATUS_CMD_UNKNOWN; } -const char *status_mime_text(int mime) +static const char *status_mime_text(int mime) { return mime_type[mime]; } Modified: tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c?view=diffrev=562174r1=562173r2=562174 == --- tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c (original) +++ tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c Thu Aug 2 09:28:29 2007 @@ -276,7 +276,7 @@ * Delete all entries of a given source type */ -int uri_worker_map_clear(jk_uri_worker_map_t *uw_map, +static int uri_worker_map_clear(jk_uri_worker_map_t *uw_map, unsigned int source_type, jk_logger_t *l) { uri_worker_record_t *uwr = NULL; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562175 - /tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c
Author: rjung Date: Thu Aug 2 09:30:45 2007 New Revision: 562175 URL: http://svn.apache.org/viewvc?view=revrev=562175 Log: Add usual info log message containing version during nsapi startup. Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Modified: tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c?view=diffrev=562175r1=562174r2=562175 == --- tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c (original) +++ tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c Thu Aug 2 09:30:45 2007 @@ -297,6 +297,8 @@ if (init_on_other_thread_is_done init_on_other_thread_is_ok) { magnus_atrestart(jk_term, NULL); rc = REQ_PROCEED; +jk_log(logger, JK_LOG_INFO, nsapi_redirector/%s initialized, + JK_VERSTRING); } /*if(wc_open(init_map, NULL, logger)) { - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562182 - in /tomcat/connectors/trunk/jk/native/netscape: Makefile.linux Makefile.solaris
Author: rjung Date: Thu Aug 2 09:54:20 2007 New Revision: 562182 URL: http://svn.apache.org/viewvc?view=revrev=562182 Log: Improve nsapi Makefiles a bit: - remove unnecessary differences between Solaris and Linux - Use CC and CFLAGS Next step will be configure based generation of the makefile. Not in this release, because automake doesn't really support Sun Studio compiler well (KPIC has been obsoleted by -xcode). Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.linux?view=diffrev=562182r1=562181r2=562182 == --- tomcat/connectors/trunk/jk/native/netscape/Makefile.linux (original) +++ tomcat/connectors/trunk/jk/native/netscape/Makefile.linux Thu Aug 2 09:54:20 2007 @@ -1,13 +1,17 @@ # Defines for example NSAPI programs running under Linux -#gcc +# gcc # If you get relocation errors, try: # 1. compiling with Sun's cc # 2. statically linking with libgcc # 3. Adjusting LD_LIBRARY_PATH to grab libgcc_s -CC_CMD=gcc -fpic -DNET_SSL -DLinux -DLINUX -D_REENTRANT -DXP_UNIX +CC=gcc +# For 64 Bit builds, add -m64 to CFLAGS +CFLAGS=-fPIC +LD_SHAREDCMD=$(CC) -shared -lthread -LD_SHAREDCMD=gcc -shared +CC_CMD=$(CC) $(CFLAGS) -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \ + -DMCC_HTTPD -DSPAPI20 OS_TYPE=linux INCLUDEDIR=$(SUITSPOT_HOME)/include @@ -28,7 +32,7 @@ all: nsapi_redirector.so -nsapi_redirector.so: $(PLUGIN_OBJ) $(JK_OBJS) +nsapi_redirector.so: $(JK_OBJS) $(PLUGIN_OBJ) $(LD_SHAREDCMD) $(JK_OBJS) $(PLUGIN_OBJ) -o nsapi_redirector.so $(EXTRA_LDDEFINES) clean: Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris?view=diffrev=562182r1=562181r2=562182 == --- tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris (original) +++ tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris Thu Aug 2 09:54:20 2007 @@ -1,20 +1,25 @@ # Defines for example NSAPI programs running under SOLARIS -#gcc +# Choose between the settings for gcc or Sun Studio compiler + +# gcc # If you get relocation errors, try: # 1. compiling with Sun's cc # 2. statically linking with libgcc # 3. Adjusting LD_LIBRARY_PATH to grab libgcc_s -CC_CMD=gcc -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \ - -DMCC_HTTPD -DSPAPI20 \ - -fPIC - -#SunStudio cc compiler -#CC_CMD=cc -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \ -# -DMCC_HTTPD -DSPAPI20 \ -# -xcode=pic32 +CC=gcc +# For 64 Bit builds, add -m64 to CFLAGS +CFLAGS=-fPIC +LD_SHAREDCMD=$(CC) -shared -lthread + +# Sun Studio cc compiler +#CC=cc +# For 64 Bit builds, add -xtarget=generic64 to CFLAGS and #LD_SHAREDCMD +#CFLAGS=-xcode=pic32 +#LD_SHAREDCMD=$(CC) -G -lthread -LD_SHAREDCMD=ld -G -fPIC +CC_CMD=$(CC) $(CFLAGS) -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \ + -DMCC_HTTPD -DSPAPI20 all: @@ -44,4 +49,4 @@ rm -f *.o nsapi_redirector.so $(JK_OBJS) %.o : %.c - $(CC_CMD) $(INCLUDE_FLAGS) -c $ + $(CC_CMD) $(INCLUDE_FLAGS) -c $ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562184 - /tomcat/connectors/trunk/jk/native/netscape/Makefile.linux
Author: rjung Date: Thu Aug 2 10:09:15 2007 New Revision: 562184 URL: http://svn.apache.org/viewvc?view=revrev=562184 Log: Fix linux Makefile error for nsapi from previous commit. Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.linux?view=diffrev=562184r1=562183r2=562184 == --- tomcat/connectors/trunk/jk/native/netscape/Makefile.linux (original) +++ tomcat/connectors/trunk/jk/native/netscape/Makefile.linux Thu Aug 2 10:09:15 2007 @@ -7,7 +7,7 @@ # 3. Adjusting LD_LIBRARY_PATH to grab libgcc_s CC=gcc # For 64 Bit builds, add -m64 to CFLAGS -CFLAGS=-fPIC +CFLAGS=-fPIC LD_SHAREDCMD=$(CC) -shared -lthread CC_CMD=$(CC) $(CFLAGS) -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562186 - /tomcat/connectors/trunk/jk/xdocs/reference/workers.xml
Author: rjung Date: Thu Aug 2 10:20:07 2007 New Revision: 562186 URL: http://svn.apache.org/viewvc?view=revrev=562186 Log: Clarify fail_on-Status behaviour in docs. Modified: tomcat/connectors/trunk/jk/xdocs/reference/workers.xml Modified: tomcat/connectors/trunk/jk/xdocs/reference/workers.xml URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/reference/workers.xml?view=diffrev=562186r1=562185r2=562186 == --- tomcat/connectors/trunk/jk/xdocs/reference/workers.xml (original) +++ tomcat/connectors/trunk/jk/xdocs/reference/workers.xml Thu Aug 2 10:20:07 2007 @@ -686,9 +686,16 @@ directive name=fail_on_status workers=AJP,SUB default=0 required=false Set this value to the HTTP status code that will cause a worker to fail -if returned from Servlet contatiner. Use this directive to deal with +if returned from Servlet container. Use this directive to deal with cases when the servlet container can temporary return non-200 responses for a short amount of time, e.g during redeployment. +p +The error page, headers and status codes of the original response will not be send back +to the client. Instead the request will result in a 503 response. +If the worker is a member of a load balancer, the member will +be put into an error state. Request failover and worker recovery will be handled +with the usual load balancer procedures. +/p p This feature has been added in bjk 1.2.20/b. /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
Hi Costin (and Remy), I had a quick look at the JdkLoggerFormatter (found in an old revision of the sandbox, it's not there any more): this formatter uses a *very* compact format. E.g. the timestamp is just the milliseconds and the log level is abbreviated with a single character. Although technically very useful, I doubt that most admins will like it at first sight, so it might not be a good default replacement for the JDK simple formatter. Still searching ... Regards, Rainer Costin Manolache wrote: I think something is missing - DirectJDKLog is looking for a JdkLoggerFormatter that would do the trick. I may have forgot to add it, I have it on my machine ( I hate too the default format ). There's also a config override allowing default properties to be loaded from a different location. Costin On 8/2/07, Remy Maucherat [EMAIL PROTECTED] wrote: Rainer Jung wrote: That's why it would be nice if someone took the burden of writing a better log formatter for j.u.l. Got it. Yea, that format is certainly grep unfriendly. Looks like Harmony has a formatter we could copy from and fix to not add the new line. http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java Yes, that could be a good starting point (although that implementation does not care about localization). It might be better to use log4j code as a starting point as it already has the pattern processing code. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562187 - /tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.java
Author: costin Date: Thu Aug 2 10:25:21 2007 New Revision: 562187 URL: http://svn.apache.org/viewvc?view=revrev=562187 Log: Add a simple one-line formatter. Added: tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.java - copied, changed from r415842, tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.java Copied: tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.java (from r415842, tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.java) URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.java?view=diffrev=562187p1=tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.javar1=415842p2=tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.javar2=562187 == --- tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.java (original) +++ tomcat/tc6.0.x/trunk/java/org/apache/juli/JdkLoggerFormatter.java Thu Aug 2 10:25:21 2007 @@ -15,7 +15,7 @@ * limitations under the License. */ -package org.apache.tomcat.util.log; +package org.apache.juli; import java.util.logging.Formatter; import java.util.logging.LogRecord; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562190 - /tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
Author: rjung Date: Thu Aug 2 10:32:56 2007 New Revision: 562190 URL: http://svn.apache.org/viewvc?view=revrev=562190 Log: Update changelog for JK. Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml 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=562190r1=562189r2=562190 == --- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Thu Aug 2 10:32:56 2007 @@ -27,8 +27,44 @@ br / subsection name=Native changelog + update +NSAPI: Add initialization startup message containing JK version. (rjung) + /update fix -Pass the 401 as OK instead sending 401 for authentication. (mturk) +General: Declare static functions as static. (jim) + /fix + update +Documentation: Clarify fail_on_status behaviour. (rjung) + /update + fix +General: Do fail_on_status before returning the response headers. (rjung) + /fix + update +NSAPI: Fix shm shutdown behaviour. (rjung) + /update + update +NSAPI: Set return status even if request ended with an error. (rjung) + /update + update +NSAPI: Allow using without shm_file on WIN32 and Netware. (rjung) + /update + fix +NSAPI: Fix Crash of nsapi for log level debug and unset refect_unsafe. (rjung) + /fix + update +NSAPI: Improve Solaris and Linux Makefiles for nsapi build. (rjung) + /update + fix +Build: Improve pid_t type detection during configure on Solaris. (rjung) + /fix + update +Build: Experimental build support for gcc on WIN32 and Netware. (fuankg) + /update + update +Build: Makefile optimizations for Apache httpd 1.3/Netware . (fuankg) + /update + fix +General: Fix missing flush bug introduced in 1.2.24. (rjung) /fix /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562201 - in /tomcat/connectors/trunk/jk/native/netscape: Makefile.linux Makefile.solaris
Author: rjung Date: Thu Aug 2 10:54:15 2007 New Revision: 562201 URL: http://svn.apache.org/viewvc?view=revrev=562201 Log: Fix comments about 64Bit building nsapi plugin in Makefiles. Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.linux?view=diffrev=562201r1=562200r2=562201 == --- tomcat/connectors/trunk/jk/native/netscape/Makefile.linux (original) +++ tomcat/connectors/trunk/jk/native/netscape/Makefile.linux Thu Aug 2 10:54:15 2007 @@ -6,7 +6,7 @@ # 2. statically linking with libgcc # 3. Adjusting LD_LIBRARY_PATH to grab libgcc_s CC=gcc -# For 64 Bit builds, add -m64 to CFLAGS +# For 64 Bit builds, add -m64 to CFLAGS and LD_SHAREDCMD CFLAGS=-fPIC LD_SHAREDCMD=$(CC) -shared -lthread Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris?view=diffrev=562201r1=562200r2=562201 == --- tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris (original) +++ tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris Thu Aug 2 10:54:15 2007 @@ -8,13 +8,13 @@ # 2. statically linking with libgcc # 3. Adjusting LD_LIBRARY_PATH to grab libgcc_s CC=gcc -# For 64 Bit builds, add -m64 to CFLAGS +# For 64 Bit builds, add -m64 to CFLAGS and LD_SHAREDCMD CFLAGS=-fPIC LD_SHAREDCMD=$(CC) -shared -lthread # Sun Studio cc compiler #CC=cc -# For 64 Bit builds, add -xtarget=generic64 to CFLAGS and #LD_SHAREDCMD +# For 64 Bit builds, add -xtarget=generic64 to CFLAGS and LD_SHAREDCMD #CFLAGS=-xcode=pic32 #LD_SHAREDCMD=$(CC) -G -lthread - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562198 - in /tomcat/connectors/trunk/jk: native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml
Author: rjung Date: Thu Aug 2 10:44:25 2007 New Revision: 562198 URL: http://svn.apache.org/viewvc?view=revrev=562198 Log: Fix shm shutdown behaviour for IIS. Modified: tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Modified: tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c?view=diffrev=562198r1=562197r2=562198 == --- tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c (original) +++ tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c Thu Aug 2 10:44:25 2007 @@ -1604,6 +1604,7 @@ } jk_map_free(rregexp_map); } +jk_shm_close(); wc_close(logger); if (logger) { jk_close_file_logger(logger); 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=562198r1=562197r2=562198 == --- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Thu Aug 2 10:44:25 2007 @@ -28,6 +28,9 @@ subsection name=Native changelog update +IIS: Fix shm shutdown behaviour. (rjung) + /update + update General: fail_on_status used in a load balancer can optionally do fail over without putting the failed worker in error state. (rjung) /update - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
Can be changed to include a better date format. I used this to look at execution times and start time - so millis was quite nice. Also more efficient to generate. Costin On 8/2/07, Rainer Jung [EMAIL PROTECTED] wrote: Hi Costin (and Remy), I had a quick look at the JdkLoggerFormatter (found in an old revision of the sandbox, it's not there any more): this formatter uses a *very* compact format. E.g. the timestamp is just the milliseconds and the log level is abbreviated with a single character. Although technically very useful, I doubt that most admins will like it at first sight, so it might not be a good default replacement for the JDK simple formatter. Still searching ... Regards, Rainer Costin Manolache wrote: I think something is missing - DirectJDKLog is looking for a JdkLoggerFormatter that would do the trick. I may have forgot to add it, I have it on my machine ( I hate too the default format ). There's also a config override allowing default properties to be loaded from a different location. Costin On 8/2/07, Remy Maucherat [EMAIL PROTECTED] wrote: Rainer Jung wrote: That's why it would be nice if someone took the burden of writing a better log formatter for j.u.l. Got it. Yea, that format is certainly grep unfriendly. Looks like Harmony has a formatter we could copy from and fix to not add the new line. http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java Yes, that could be a good starting point (although that implementation does not care about localization). It might be better to use log4j code as a starting point as it already has the pattern processing code. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29936] - XML parser loading problems by container
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29936. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29936 --- Additional Comments From [EMAIL PROTECTED] 2007-08-02 11:08 --- Eddy, which particular sourceforge webapp did you use to test this? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43002] - NIO connector performance issue in 6.0.13
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43002 --- Additional Comments From [EMAIL PROTECTED] 2007-08-02 11:43 --- Created an attachment (id=20581) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20581action=view) JSP That renerates a variable response buffer with configurable sleep delays -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43002] - NIO connector performance issue in 6.0.13
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43002 --- Additional Comments From [EMAIL PROTECTED] 2007-08-02 11:44 --- Created an attachment (id=20582) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20582action=view) Grinder config file for load test -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43002] - NIO connector performance issue in 6.0.13
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43002 --- Additional Comments From [EMAIL PROTECTED] 2007-08-02 11:46 --- Created an attachment (id=20583) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20583action=view) Grinder/JPython script that calls response generator JSP for -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43002] - NIO connector performance issue in 6.0.13
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43002 --- Additional Comments From [EMAIL PROTECTED] 2007-08-02 11:53 --- I've added a simple JSP page to help work the issue. The Grinder load test scripts are now separate attachments. The JSP page is pretty simplistic and I had to push the server hard. It appears that the Content-Length header does not match the response buffer size. During one of the test runs I got the following exeception in the system logs, although it seemed to be an isolated occurance. === 2007-08-01 17:09:20,364 [http-8080-exec-9] ERROR org.apache.catalina.connector.CoyoteAdapter - An exception or error occurred in the container during the request processing java.nio.BufferOverflowException at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:311) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:290) at sun.nio.ch.IOUtil.write(IOUtil.java:70) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:111) at org.apache.tomcat.util.net.NioBlockingSelector.write (NioBlockingSelector.java:57) at org.apache.tomcat.util.net.NioSelectorPool.write (NioSelectorPool.java:135) at org.apache.tomcat.util.net.NioSelectorPool.write (NioSelectorPool.java:130) at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket (InternalNioOutputBuffer.java:433) at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer (InternalNioOutputBuffer.java:761) at org.apache.coyote.http11.InternalNioOutputBuffer.endRequest (InternalNioOutputBuffer.java:398) at org.apache.coyote.http11.Http11NioProcessor.action (Http11NioProcessor.java:1089) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.catalina.connector.OutputBuffer.close (OutputBuffer.java:276) at org.apache.catalina.connector.Response.finishResponse (Response.java:486) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:285) at org.apache.coyote.http11.Http11NioProcessor.process (Http11NioProcessor.java:896) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process (Http11NioProtocol.java:705) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run (NioEndpoint.java:2049) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask (ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) 2007-08-01 17:09:56,255 [http-8080-exec-11] ERROR org.apache.catalina.connector.CoyoteAdapter - An exception or error occurred in the container during the request processing java.nio.BufferOverflowException at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:311) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:290) at sun.nio.ch.IOUtil.write(IOUtil.java:70) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:111) at org.apache.tomcat.util.net.NioBlockingSelector.write (NioBlockingSelector.java:57) at org.apache.tomcat.util.net.NioSelectorPool.write (NioSelectorPool.java:135) at org.apache.tomcat.util.net.NioSelectorPool.write (NioSelectorPool.java:130) at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket (InternalNioOutputBuffer.java:433) at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer (InternalNioOutputBuffer.java:761) at org.apache.coyote.http11.InternalNioOutputBuffer.endRequest (InternalNioOutputBuffer.java:398) at org.apache.coyote.http11.Http11NioProcessor.action (Http11NioProcessor.java:1089) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.catalina.connector.OutputBuffer.close (OutputBuffer.java:276) at org.apache.catalina.connector.Response.finishResponse (Response.java:486) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:285) at org.apache.coyote.http11.Http11NioProcessor.process (Http11NioProcessor.java:896) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process (Http11NioProtocol.java:705) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run (NioEndpoint.java:2049) at
Re: svn commit: r562194 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp13.h native/common/jk_ajp_common.c native/common/jk_lb_worker.c xdocs/miscellaneous/changelog.xml xdocs/reference/workers.
On Aug 2, 2007, at 1:42 PM, [EMAIL PROTECTED] wrote: == --- tomcat/connectors/trunk/jk/native/common/jk_ajp13.h (original) +++ tomcat/connectors/trunk/jk/native/common/jk_ajp13.h Thu Aug 2 10:42:23 2007 @@ -45,7 +45,8 @@ #define JK_CLIENT_RD_ERROR (-6) #define JK_CLIENT_WR_ERROR (-7) #define JK_STATUS_ERROR (-8) -#define JK_REPLY_TIMEOUT(-9) +#define JK_STATUS_FATAL_ERROR (-9) +#define JK_REPLY_TIMEOUT(-10) I'm curious... One reason to use C #defines is to abstract out the macro and their values. So why, when adding entries to we force JK_REPLY_TIMEOUT to always be the lowest value? It shouldn't matter what the real values are, right? This is especially true if we ever want to leak these out externally :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562242 - in /tomcat/connectors/trunk/jk/native/netscape: Makefile.linux Makefile.solaris
Author: rjung Date: Thu Aug 2 13:27:03 2007 New Revision: 562242 URL: http://svn.apache.org/viewvc?view=revrev=562242 Log: Another round of Makefile changes for nsapi (Linux/Solaris). Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.linux URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.linux?view=diffrev=562242r1=562241r2=562242 == --- tomcat/connectors/trunk/jk/native/netscape/Makefile.linux (original) +++ tomcat/connectors/trunk/jk/native/netscape/Makefile.linux Thu Aug 2 13:27:03 2007 @@ -6,12 +6,14 @@ # 2. statically linking with libgcc # 3. Adjusting LD_LIBRARY_PATH to grab libgcc_s CC=gcc -# For 64 Bit builds, add -m64 to CFLAGS and LD_SHAREDCMD -CFLAGS=-fPIC -LD_SHAREDCMD=$(CC) -shared -lthread +# For 64 Bit builds, add -m64 to EXTRA_CFLAGS +EXTRA_CFLAGS=-fPIC -pthread +LDFLAGS=-shared -CC_CMD=$(CC) $(CFLAGS) -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \ - -DMCC_HTTPD -DSPAPI20 +CC_CMD=$(CC) $(CFLAGS) $(EXTRA_CFLAGS) \ + -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 + +LD_SHAREDCMD=$(CC) $(LDFLAGS) $(CFLAGS) $(EXTRA_CFLAGS) OS_TYPE=linux INCLUDEDIR=$(SUITSPOT_HOME)/include Modified: tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris?view=diffrev=562242r1=562241r2=562242 == --- tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris (original) +++ tomcat/connectors/trunk/jk/native/netscape/Makefile.solaris Thu Aug 2 13:27:03 2007 @@ -8,18 +8,20 @@ # 2. statically linking with libgcc # 3. Adjusting LD_LIBRARY_PATH to grab libgcc_s CC=gcc -# For 64 Bit builds, add -m64 to CFLAGS and LD_SHAREDCMD -CFLAGS=-fPIC -LD_SHAREDCMD=$(CC) -shared -lthread +# For 64 Bit builds, add -m64 to EXTRA_CFLAGS +EXTRA_CFLAGS=-fPIC -pthread +LDFLAGS=-shared # Sun Studio cc compiler #CC=cc -# For 64 Bit builds, add -xtarget=generic64 to CFLAGS and LD_SHAREDCMD -#CFLAGS=-xcode=pic32 -#LD_SHAREDCMD=$(CC) -G -lthread +# For 64 Bit builds, add -xtarget=generic64 to EXTRA_CFLAGS +#EXTRA_CFLAGS=-xcode=pic32 -mt +#LDFLAGS=-G -CC_CMD=$(CC) $(CFLAGS) -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX \ - -DMCC_HTTPD -DSPAPI20 +CC_CMD=$(CC) $(CFLAGS) $(EXTRA_CFLAGS) \ + -DNET_SSL -DSOLARIS -D_REENTRANT -DXP_UNIX -DMCC_HTTPD -DSPAPI20 + +LD_SHAREDCMD=$(CC) $(LDFLAGS) $(CFLAGS) $(EXTRA_CFLAGS) all: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
Costin Manolache wrote: Can be changed to include a better date format. I used this to look at execution times and start time - so millis was quite nice. Also more efficient to generate. Ideally, it would use a pattern property to configure it, like: logger_prefix.org.apache.juli.PatternFormatter.pattern Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r562250 - in /tomcat/connectors/trunk/jk/xdocs: miscellaneous/changelog.xml webserver_howto/nes.xml
Author: rjung Date: Thu Aug 2 13:44:23 2007 New Revision: 562250 URL: http://svn.apache.org/viewvc?view=revrev=562250 Log: Improve nsapi build description for Unix. Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml tomcat/connectors/trunk/jk/xdocs/webserver_howto/nes.xml 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=562250r1=562249r2=562250 == --- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Thu Aug 2 13:44:23 2007 @@ -35,6 +35,9 @@ do fail over without putting the failed worker in error state. (rjung) /update update +NSAPI: Improve build description for Unix. (rjung) + /update + update NSAPI: Add initialization startup message containing JK version. (rjung) /update fix Modified: tomcat/connectors/trunk/jk/xdocs/webserver_howto/nes.xml URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/webserver_howto/nes.xml?view=diffrev=562250r1=562249r2=562250 == --- tomcat/connectors/trunk/jk/xdocs/webserver_howto/nes.xml (original) +++ tomcat/connectors/trunk/jk/xdocs/webserver_howto/nes.xml Thu Aug 2 13:44:23 2007 @@ -463,7 +463,7 @@ /section section name=Building NSAPI so plugin redirector for Unix p -The redirector requires either gcc or the native Solaris cc compiler. +The redirector requires either gcc (Linux) or gcc or the Sun cc compiler (Solaris). The steps that you need to take are: ul @@ -477,7 +477,15 @@ Change directory to the nsapi netscape directory (./netstape). /li li -Edit bMakefile.solaris/b and update the SUITSPOT_HOME and JAVE_HOME path to reflect your own Netscape server installation. +Set environment variables JAVA_HOME resp. SUITSPOT_HOME to the location of your Java installation +resp. Netscape server installation. Depending on the web server version, you must add the subdirectory +quot;pluginsquot; to SUITSPOT_HOME. +The variable is correct, if the file $SUITSPOT_HOME/include/nsapi.h exists. +/li +li +Edit bMakefile.solaris/b resp. bMakefile.linux/b and update the variables according to your needs. +In the Solaris Makefile, you need to switch the commented lines in order to use the Sun compiler cc +instead of GNU gcc. /li li Make the source with gmake. @@ -490,7 +498,11 @@ typedos./configure --enable-netscape/typedos notedosChange directory to the nsapi netscape directory/notedos typedoscd netscape/typedos -notedosEdit Makefile.solaris/notedos +notedosSet JAVA_HOME (ksh example)/notedos +typedosexport JAVA_HOME=/path/to/my/java/typedos +notedosSet SUITSPOT_HOME (ksh example)/notedos +typedosexport SUITSPOT_HOME=/path/to/my/netscape/server/typedos +notedosEdit the Makefile/notedos typedosvi Makefile.solaris/typedos notedosMake the source with gmake/notedos typedosgmake -f Makefile.solaris/typedos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r562194 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp13.h native/common/jk_ajp_common.c native/common/jk_lb_worker.c xdocs/miscellaneous/changelog.xml xdocs/reference/workers
And in fact it doesn't matter. I found it more logical, to have JK_STATUS_ERROR and JK_STATUS_FATAL_ERROR closer together (for those reading the code). The constants are not used outside JK, so there is no compatibility problem. It looks like your are closely following todays JK changes. I really appreciate that! Unless you find problems, I just now commited my last change (hopefully) for 1.2.25. Regards, Rainer Jim Jagielski wrote: On Aug 2, 2007, at 1:42 PM, [EMAIL PROTECTED] wrote: == --- tomcat/connectors/trunk/jk/native/common/jk_ajp13.h (original) +++ tomcat/connectors/trunk/jk/native/common/jk_ajp13.h Thu Aug 2 10:42:23 2007 @@ -45,7 +45,8 @@ #define JK_CLIENT_RD_ERROR (-6) #define JK_CLIENT_WR_ERROR (-7) #define JK_STATUS_ERROR (-8) -#define JK_REPLY_TIMEOUT(-9) +#define JK_STATUS_FATAL_ERROR (-9) +#define JK_REPLY_TIMEOUT(-10) I'm curious... One reason to use C #defines is to abstract out the macro and their values. So why, when adding entries to we force JK_REPLY_TIMEOUT to always be the lowest value? It shouldn't matter what the real values are, right? This is especially true if we ever want to leak these out externally :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43003] - Separate dependent component download and build targets
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43003. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43003 --- Additional Comments From [EMAIL PROTECTED] 2007-08-02 16:51 --- Created an attachment (id=20586) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20586action=view) Servlet response generator -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43002] - NIO connector performance issue in 6.0.13
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43002 --- Additional Comments From [EMAIL PROTECTED] 2007-08-02 16:48 --- Update.I wrote a simple response generator servlet and re-ran the tests. Now performance on 6.0.13 is significantly *FASTER*. However, I'm seeing a fair number of HTTPClient errors from Grinder as well as consistent buffer overflow exceptions. This leads me to believe that the bottleneck has now shifted to the application code. I've attached the test servlet. Here are the stack traces: === Java exception whilst invoking test runner File /apps/grinder-3.0/projects/TeaBenchmark/smallest-servlet- 400rps.py, line 40, in __call__ Caused by: java.io.IOException: HTTPClient.ParseException: Didn't find valid chunk length: at HTTPClient.StreamDemultiplexor.read(StreamDemultiplexor.java:372) at HTTPClient.RespInputStream.read(RespInputStream.java:155) at HTTPClient.HTTPResponse.readResponseData(HTTPResponse.java:1011) at HTTPClient.HTTPResponse.getData(HTTPResponse.java:515) at net.grinder.plugin.http.HTTPRequest$AbstractRequest.getHTTPResponse (HTTPRequest.java:888) at net.grinder.plugin.http.HTTPRequest.GET(HTTPRequest.java:385) at net.grinder.plugin.http.HTTPRequest.GET(HTTPRequest.java:360) at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) TOMCAT LOG STACK TRACE FOLLOWS: 2007-08-02 15:44:04,453 [http-8080-exec-17] ERROR org.apache.catalina.connector.CoyoteAdapter - An exception or error occurred in the container during the request processing java.nio.BufferOverflowException at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:311) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:290) at sun.nio.ch.IOUtil.write(IOUtil.java:70) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:111) at org.apache.tomcat.util.net.NioBlockingSelector.write (NioBlockingSelector.java:57) at org.apache.tomcat.util.net.NioSelectorPool.write (NioSelectorPool.java:135) at org.apache.tomcat.util.net.NioSelectorPool.write (NioSelectorPool.java:130) at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket (InternalNioOutputBuffer.java:433) at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer (InternalNioOutputBuffer.java:761) at org.apache.coyote.http11.InternalNioOutputBuffer.endRequest (InternalNioOutputBuffer.java:398) at org.apache.coyote.http11.Http11NioProcessor.action (Http11NioProcessor.java:1089) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.catalina.connector.OutputBuffer.close (OutputBuffer.java:276) at org.apache.catalina.connector.Response.finishResponse (Response.java:486) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:285) at org.apache.coyote.http11.Http11NioProcessor.process (Http11NioProcessor.java:896) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process (Http11NioProtocol.java:705) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run (NioEndpoint.java:2049) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask (ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) 2007-08-02 15:45:24,687 [http-8080-exec-11] ERROR org.apache.catalina.connector.CoyoteAdapter - An exception or error occurred in the container during the request processing java.nio.BufferOverflowException at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:311) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:290) at sun.nio.ch.IOUtil.write(IOUtil.java:70) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:111) at org.apache.tomcat.util.net.NioBlockingSelector.write (NioBlockingSelector.java:57) at org.apache.tomcat.util.net.NioSelectorPool.write (NioSelectorPool.java:135) at
DO NOT REPLY [Bug 43019] New: - valid absolute request uris + mod_jk 1.2.23 return 400 Invalid URI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43019. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43019 Summary: valid absolute request uris + mod_jk 1.2.23 return 400 Invalid URI Product: Tomcat 6 Version: 6.0.13 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Problem noticed after upgrading to 1.2.23 to pick up the fix for http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1860 mod_jk now by default uses JkOptions +ForwardURICompatUnparsed Problem seen with Tomcat 5.0.28 through 6.0.13 and other versions are likely affected. The problem: Some HTTP clients send requests like: POST http://host/abs_path HTTP/1.1 Host:host When Tomcat is fronted by mod_jk 1.2.23, requests like now produce 400 Invalid URI responses. After more testing, we found: (1) client - (apache + mod_jk) - tomcat: produces 400 Invalid URI response (2) client - (apache + mod_jk) - (tomcat + apr): produces 200 OK response (3) client - tomcat: produces 200 OK response Stepping through case (1) with a debugger, request was rejected at this point: package org.apache.catalina.connector; public class CoyoteAdapter { public static boolean normalize(MessageBytes uriMB) { ... // The URL must start with '/' if (b[start] != (byte) '/') { return false; } The byte buffer contained the full http://host/abs_path request uri. Comparing the differences between org.apache.coyote.ajp.AjpAprProcessor (case 2, works OK) and org.apache.jk.common.HandlerRequest (case 1, broken), we noticed that AjpAprProcessor converts http://host/abs_path to /abs_path in the STAGE_PREPARE phase but HandlerRequest does not. To fix, we just copied the code from AjpAprProcessor to HandlerRequest essentially unchanged: package org.apache.jk.common; public class HandlerRequest { ... private int decodeRequest( Msg msg, MsgContext ep, MessageBytes tmpMB ) throws IOException{ ... decodeHeaders( ep, msg, req, tmpMB ); decodeAttributes( ep, msg, req, tmpMB ); rp.setStage(Constants.STAGE_PREPARE); // start yahoo! modified: // note this code was taken from AjpProcessor.prepare() - other code // from that method should also be considered for inclusion here // Check for a full URI (including protocol://host:port/) ByteChunk uriBC = req.requestURI().getByteChunk(); if (uriBC.startsWithIgnoreCase(http, 0)) { int pos = uriBC.indexOf(://, 0, 3, 4); int uriBCStart = uriBC.getStart(); int slashPos = -1; if (pos != -1) { byte[] uriB = uriBC.getBytes(); slashPos = uriBC.indexOf('/', pos + 3); if (slashPos == -1) { slashPos = uriBC.getLength(); // Set URI as / req.requestURI().setBytes (uriB, uriBCStart + pos + 1, 1); } else { req.requestURI().setBytes (uriB, uriBCStart + slashPos, uriBC.getLength() - slashPos); } MessageBytes hostMB = req.getMimeHeaders().setValue(host); hostMB.setBytes(uriB, uriBCStart + pos + 3, slashPos - pos - 3); } } // end yahoo! modified MessageBytes valueMB = req.getMimeHeaders().getValue(host); parseHost(valueMB, req); // set cookies on request now that we have all headers req.getCookies().setHeaders(req.getMimeHeaders()); ... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: My personal opinion: java.util.logging very much lacks a good formatter. The default 2 line formatting of messages, splitting timestamps and message in separate lines, is not really useful in production. Many ad hoc log analysis practices work on a line oriented basis. How would exception stack traces be handled? That's an important consideration because a stack trace is the first thing people ask for when someone has a problem. :-) I like the idea of one line per entry, but stack traces don't seem to fit into that format. If you collapse a stack trace onto one line, it's a lot harder to read. If you keep the multi-line format for stack traces, you keep the same problem with log analysis practices that work on a line oriented basis. -- Len - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
On 8/2/07, Len Popp [EMAIL PROTECTED] wrote: On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: My personal opinion: java.util.logging very much lacks a good formatter. The default 2 line formatting of messages, splitting timestamps and message in separate lines, is not really useful in production. Many ad hoc log analysis practices work on a line oriented basis. How would exception stack traces be handled? That's an important consideration because a stack trace is the first thing people ask for when someone has a problem. :-) I like the idea of one line per entry, but stack traces don't seem to fit into that format. If you collapse a stack trace onto one line, it's a lot harder to read. If you keep the multi-line format for stack traces, you keep the same problem with log analysis practices that work on a line oriented basis. It's not only log tools who dislike the 2-line format - also humans. For a tool - detecting the stack trace is not that hard, it's a simple pattern. But maybe a compact binary format would be more interesting for tools, and could be converted to different layouts for people. Costin -- Len - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
On 8/3/07, Costin Manolache [EMAIL PROTECTED] wrote: On 8/2/07, Len Popp [EMAIL PROTECTED] wrote: On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: My personal opinion: java.util.logging very much lacks a good formatter. The default 2 line formatting of messages, splitting timestamps and message in separate lines, is not really useful in production. Many ad hoc log analysis practices work on a line oriented basis. How would exception stack traces be handled? That's an important consideration because a stack trace is the first thing people ask for when someone has a problem. :-) I like the idea of one line per entry, but stack traces don't seem to fit into that format. If you collapse a stack trace onto one line, it's a lot harder to read. If you keep the multi-line format for stack traces, you keep the same problem with log analysis practices that work on a line oriented basis. It's not only log tools who dislike the 2-line format - also humans. For a tool - detecting the stack trace is not that hard, it's a simple pattern. But maybe a compact binary format would be more interesting for tools, and could be converted to different layouts for people. Costin Oh, I'm one of the humans who prefers one line per entry - at least for short entries. I'm not against changing the log format. I'm just not sure if you can put a stack trace on one line and keep it readable. I wouldn't like to have a binary file format that I need a special program to read, or that is incompatible with standard tools like grep, tail, etc. -- Len - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]