Re: JK 1.2.14 core dump oddity
William A. Rowe, Jr. wrote: At 03:04 PM 7/12/2005, William A. Rowe, Jr. wrote: It's not the return OK; my bad. Something deeper is going on here, some interaction with Apache 2, having to do with the request_rec status not being bubbled back to the origin error. But if anyone has clues to point me at, I'd appreciate it. Ok, most httpd modules presume r-status is 200, and only set it in the case of exceptions. This is why a cgi with no 'Status:' header will return the error code if it is configured as the errordocument, but if 'Status: 200' is passed with the headers, the 'error code' is lost. In mod_jk's case, we always set r-status. So we could decide to do nothing for 200 OK, or leave as is. In mod_jk r-status is set in ws_start_response(), that is called the first time ws_write is called or directly when Tomcat sends the headers. Of course you get the error page defined in Tomcat not the one defined in httpd.conf. But it seems that alot of modules make this 'mistake' and it really should be up to httpd to 'fix' the error result if it's using a given resource as an 'error page'. So I'm proposing to httpd that it gets fixed on that side. Bill - 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]
Re: JK 1.2.14 core dump oddity
William A. Rowe, Jr. wrote: Line 1971 of jk/native/apache-2.0/mod_jk.c says... return OK; /* NOT r-status, even if it has changed. */ This goes back to version 1.1 of the module; the question is; WHY? Well, mod_jk presumes that when Tomcat serves the page it is 200. You can make a custom error pages in Tomcat directly without using ErrorDocument 404 /xxx Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.14 core dump oddity
It's not the return OK; my bad. Something deeper is going on here, some interaction with Apache 2, having to do with the request_rec status not being bubbled back to the origin error. But if anyone has clues to point me at, I'd appreciate it. At 02:52 PM 7/12/2005, William A. Rowe, Jr. wrote: Something's not quite right in mod_jk-land. The pertinent httpd.conf is; ErrorDocument 404 /examplestomcat/error.jsp Alias /examplestomcat /local0/test/webapps/examplestomcat JkMount /examplestomcat/*.jsp ajp13 when the 404 causes error.jsp to be returned, the response code is unset from 404 to 200-ok. This behavior is not a regression, seems it's been that way for a long (1.2.8 or earlier) time. Line 1971 of jk/native/apache-2.0/mod_jk.c says... return OK; /* NOT r-status, even if it has changed. */ This goes back to version 1.1 of the module; the question is; WHY? Bill Bill - 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]
Re: JK 1.2.14 core dump oddity
- Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Tuesday, July 12, 2005 12:52 PM Subject: JK 1.2.14 core dump oddity Something's not quite right in mod_jk-land. The pertinent httpd.conf is; ErrorDocument 404 /examplestomcat/error.jsp Alias /examplestomcat /local0/test/webapps/examplestomcat JkMount /examplestomcat/*.jsp ajp13 when the 404 causes error.jsp to be returned, the response code is unset from 404 to 200-ok. This behavior is not a regression, seems it's been that way for a long (1.2.8 or earlier) time. It goes back at least to 1.1.x. Line 1971 of jk/native/apache-2.0/mod_jk.c says... return OK; /* NOT r-status, even if it has changed. */ This goes back to version 1.1 of the module; the question is; WHY? You're the httpd expert, not me ;-). As I understand it, it is to have httpd return the Tomcat response code (which won't be 404 unless error.jsp explictly sets it to that). Bill Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.14 core dump oddity
At 03:04 PM 7/12/2005, William A. Rowe, Jr. wrote: It's not the return OK; my bad. Something deeper is going on here, some interaction with Apache 2, having to do with the request_rec status not being bubbled back to the origin error. But if anyone has clues to point me at, I'd appreciate it. Ok, most httpd modules presume r-status is 200, and only set it in the case of exceptions. This is why a cgi with no 'Status:' header will return the error code if it is configured as the errordocument, but if 'Status: 200' is passed with the headers, the 'error code' is lost. In mod_jk's case, we always set r-status. So we could decide to do nothing for 200 OK, or leave as is. But it seems that alot of modules make this 'mistake' and it really should be up to httpd to 'fix' the error result if it's using a given resource as an 'error page'. So I'm proposing to httpd that it gets fixed on that side. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
