Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
Glenn, On Mon, 06 Jan 2003 19:30:42 -0600, Glenn Nielsen [EMAIL PROTECTED] said: Thanks for reporting this. I have changed the code so that if there is no content only status codes = 400 are passed back through apache. The original patch was made so that when an error occurred at the Ajp13Processor layer it could propogated back to the browser correctly instead of a blank page being displayed. and it was a welcome fix (now, when Tomcat is being restarted, instead of the JSP being displayed as HTML, I can use a custom error page). Please test from a CVS build and let me know if this fixes the problem for you. I just updated mod_jk.c from CVS and the fix of only passing empty content errors = 400 seems to work in my quick testing. Thanks, Adi Aditya wrote: On 2 Jan 2003 12:58:58 -, [EMAIL PROTECTED] said: glenn 2003/01/02 04:58:58 Modified: jk/native/apache-1.3 mod_jk.c jk/native/apache-2.0 mod_jk.c Log: Make sure http errors are handled by Apache if not handled by Tomcat Revision Changes Path 1.34 +6 -1 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c This fix seems to cause container form-based authentication to have problems - instead of the usual sequence of: 1) GET protected page - 302 to login page 2) GET login page - 200 retrieved 3) POST login page - 302 to protected page 4) GET protected page - 200 retrieved The *first* time I try to go to the protected page, instead of (4), I get: HTTP status 400 (invalid direct reference...) However, if I then try to get the protected page a *second* time, it works fine... reverting to a verison of mod_jk that does not include the below fix doesn't evidence this problem... Adi -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
On 2 Jan 2003 12:58:58 -, [EMAIL PROTECTED] said: glenn 2003/01/02 04:58:58 Modified: jk/native/apache-1.3 mod_jk.c jk/native/apache-2.0 mod_jk.c Log: Make sure http errors are handled by Apache if not handled by Tomcat Revision Changes Path 1.34 +6 -1 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c This fix seems to cause container form-based authentication to have problems - instead of the usual sequence of: 1) GET protected page - 302 to login page 2) GET login page - 200 retrieved 3) POST login page - 302 to protected page 4) GET protected page - 200 retrieved The *first* time I try to go to the protected page, instead of (4), I get: HTTP status 400 (invalid direct reference...) However, if I then try to get the protected page a *second* time, it works fine... reverting to a verison of mod_jk that does not include the below fix doesn't evidence this problem... Adi -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
Since it seems like people have totally different needs in regards to static files and redirection of 'ambiguous' directory requests to Tomcat, I went with the option ForwardDirectories, which can be specified in JkOptions. It is off by default. When turned off, any directory that doesn't contain any of the files specified in DirectoryIndex will be handled by Apache, by whichever module does automatic directory indexing (normally mod_autoindex). When turned on, such requests will be forwarded to Tomcat for resolution. This then gives Tomcat the opportunity to do its magic and serve whatever it pleases, including the contents of the directory, similar to mod_autoindex, or whatever else. This, of course, is only applicable to mod_jk 1.2.0. mod_jk2 still transfers all such requests to Tomcat, I believe. I'll have to learn a great deal more about it in order to apply something like the above to it. Bojan On Wed, 2002-07-24 at 14:48, [EMAIL PROTECTED] wrote: bojan 2002/07/23 21:48:52 Modified:jk/native/apache-2.0 mod_jk.c -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
I have tested this with and without DirectoryIndex. In case there is DirectoryIndex, the physical file(s) are stat and if that's successful mod_dir does its thing. It works nicely for at least 2 different file extensions (in my case *.jsp and *.vm). If the files cannot be stat, it's up the jk_handler() to decide, which covers the cases where there are no physical files present. The requests will still end up in Tomcat if there is a mapping. If there is no DirectoryIndex, jk_handler() makes its own decisions about what's going to get served. Anything that is mapped will end up in Tomcat. Note that this whole thing does not affect real static files like index.html. Tomcat will never serve (or attempt to serve) those, unless they are mapped to Tomcat by some other means, not the extension. So I hope this satisfies all relevant concerns for now. Important note: --- THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC. - Do you want me to: [ ] Revert it back to what it was before I put my fingers in it [ ] Leave it alone [ ] Attempt to apply the same stuff that's in this patch to it Bojan On Tue, 2002-07-23 at 07:03, [EMAIL PROTECTED] wrote: bojan 2002/07/22 14:03:19 Modified:jk/native/apache-2.0 mod_jk.c Log: Put back DIR_MAGIC_TYPE in case there is no DirectoryIndex and/or no pysical files to stat. Lose one stat, not really needed. Fix a typo. Revision ChangesPath 1.52 +10 -5 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c Index: mod_jk.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v retrieving revision 1.51 retrieving revision 1.52 diff -u -r1.51 -r1.52 --- mod_jk.c22 Jul 2002 02:48:11 - 1.51 +++ mod_jk.c22 Jul 2002 21:03:19 - 1.52 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
On 23 Jul 2002, Bojan Smojver wrote: Important note: --- THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC. - Do you want me to: [ ] Revert it back to what it was before I put my fingers in it [ ] Leave it alone [+1] Attempt to apply the same stuff that's in this patch to it Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
Before I do that, some questions about uriEnv in jk2_handler(), since that part is very different to mod_jk. The initial test involves asking: if (uriEnv==NULL || strcmp(r-handler,JK_HANDLER)!= 0) and if so, the whole thing is skipped. After the first test, there is the second test that goes: if( uriEnv == NULL ) Obviously, that's not possible, since the first test would kick us out of the function. But, in case the first test was changed to not involve asking if uriEnv is null, the the code after the second test would hit a NULL pointer here: if( uriEnv-mbean-debug 0 ) How do I go through this mine field? What's going to be the value of uriEnv if r-handler is DIR_MAGIC_TYPE? If it's going to be NULL, I have to change a lot of code in the whole function to make sure we don't bump into a NULL pointer somewhere... Bojan On Tue, 2002-07-23 at 07:44, [EMAIL PROTECTED] wrote: On 23 Jul 2002, Bojan Smojver wrote: Important note: --- THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC. - Do you want me to: [ ] Revert it back to what it was before I put my fingers in it [ ] Leave it alone [+1] Attempt to apply the same stuff that's in this patch to it Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
I made an initial, most likely broken commit of this code for mod_jk2. Can you go through it as I'm making assumptions in there that I am not sure about. They are just a parallel from mod_jk, but that could be totally bogus. At least there is some 'meat' for you guys to play with. Bojan On Tue, 2002-07-23 at 07:44, [EMAIL PROTECTED] wrote: On 23 Jul 2002, Bojan Smojver wrote: Important note: --- THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC. - Do you want me to: [ ] Revert it back to what it was before I put my fingers in it [ ] Leave it alone [+1] Attempt to apply the same stuff that's in this patch to it Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
On 23 Jul 2002, Bojan Smojver wrote: Before I do that, some questions about uriEnv in jk2_handler(), since that part is very different to mod_jk. The initial test involves asking: if (uriEnv==NULL || strcmp(r-handler,JK_HANDLER)!= 0) uriEnv == null means no match was found. It is set by either jk2_translate or by a JkSet in a Location context. After the first test, there is the second test that goes: if( uriEnv == NULL ) Yes, that's some old code that tryed to support the case when someone would do: Location SetHandler jakarta/servlet /Location I'll remove it - as you mention, it's obviously not working, and I'm not sure it is a good idea - doing a JkSet has the same effect and it's not worth the extra complexity. How do I go through this mine field? What's going to be the value of uriEnv if r-handler is DIR_MAGIC_TYPE? If it's going to be NULL, I have It's jk_translate who decides if a request is to be handled by jk ( by mapping it to a uriEnv ). You can add a test for r-handler==DIR_MAGIC_TYPE, but don't assume any uriEnv is set. uriEnv is the equivalent of a servlet mapping ( or the Container in 3.3 ). You should still do an internal mapping in handler and find some per/context or per/vhost uriEnv. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
I have reworked the code to take care of aliases (i.e. to use what Apache already knows about them from the main request). Please note that URI will be left unchanged, so unless Tomcat knows about the aliases as well, nothing will get served. I will not commit the change to mod_jk2 since there are major objections to the code in the first place. Please consider this as just an attempt to correct the brain dead code that involved DocumentRoot, rather then actual file location and mixing URI's with filenames, nothing more. Bojan On Mon, 2002-07-22 at 08:34, [EMAIL PROTECTED] wrote: bojan 2002/07/21 15:34:25 Modified:jk/native/apache-2.0 mod_jk.c -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
Thanks. I'll download an retest. Bojan On Thu, 2002-06-13 at 00:33, GOMEZ Henri wrote: This should fix the problem reported by Bojan. What about tagging jtc for jk_1_2_0 release ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 4:31 PM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c hgomez 2002/06/12 07:31:09 Modified:jk/native/apache-2.0 mod_jk.c Log: Fix the incorrect error reported when a worker is defined but didn't exist (reported by Bojan) Revision ChangesPath 1.45 +4 -1 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c Index: mod_jk.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v retrieving revision 1.44 retrieving revision 1.45 diff -u -r1.44 -r1.45 --- mod_jk.c 8 May 2002 00:45:33 - 1.44 +++ mod_jk.c 12 Jun 2002 14:31:09 - 1.45 @@ -1324,6 +1324,9 @@ return OK;/* NOT r-status, even if it has changed. */ } } + else + return HTTP_INTERNAL_SERVER_ERROR; + } return DECLINED; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
I will apply the patch to 1.3.
Are we still maintaining the second copy of jk in 3.3 tree ?
Larry - can we start removing the duplicated util and c code ?
IMHO the j-t-c code ( the 'native1' side ) is as stable as the
one in 3.3, and it would simplify our life to deal with a single
one.
Costin
did somebody report these patches to apache 1.3 ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 02, 2002 2:42 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0
mod_jk.c
costin 02/04/01 16:42:11
Modified:jk/native/apache-2.0 mod_jk.c
Log:
If jk config is broken, report the error - but don't exit.
Revision ChangesPath
1.41 +4 -4
jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- mod_jk.c 28 Feb 2002 22:45:50 - 1.40
+++ mod_jk.c 2 Apr 2002 00:42:11 - 1.41
@@ -60,7 +60,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat
*
* Author: Gal Shachor [EMAIL PROTECTED]
*
* Henri Gomez [EMAIL PROTECTED]
*
- * Version: $Revision: 1.40 $
*
+ * Version: $Revision: 1.41 $
*
***
/
/*
@@ -1507,9 +1507,9 @@
/* if(map_alloc(init_map)) { */
if( ! map_read_properties(init_map, conf-worker_file)) {
if( map_size( init_map ) == 0 ) {
-jk_error_exit(APLOG_MARK, APLOG_EMERG, s,
- pconf, No worker file and no
worker options in httpd.conf \n
- use JkWorkerFile or JkWorker to
set workers);
+ap_log_error(APLOG_MARK, APLOG_STARTUP |
APLOG_NOERRNO, APLOG_EMERG,
+ NULL, No worker file and no
worker options in httpd.conf \n
+ use JkWorkerFile to set workers\n);
return;
}
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
