Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
I also tried this and everything worked nicely.
NormW wrote:
Good morning All.
Just tried Jean's recent change to mod_jk2.c and _pleased_ to say JkUriSet
now registers correctly the same as a [uri] section, and can access /admin
with only a Location in the httpd.conf. I did note there were duplicate
uri objects created (based on their name) if the same uri spec was in both
files, but in any case this is a lot closer to theory than in the past.
Thanks Jean.
Norm
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 12:22 AM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2
mod_jk2.c
jfclere 2004/03/31 06:22:04
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
Fix handling of id added in jk2_create_dir_config().
I do not see why we need this id... May because jk2_merge_dir_config()
was buggy.
That fixes PR 18472 and 28916.
Revision ChangesPath
1.82 +33 -16
jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- mod_jk2.c 21 Mar 2004 09:44:30 - 1.81
+++ mod_jk2.c 31 Mar 2004 14:22:04 - 1.82
@@ -221,14 +221,25 @@
strcpy(tmp_full_url, s-server_hostname);
strcat(tmp_full_url, uriEnv-uri);
}
+
uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
uri, tmp_full_url);
uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
path, cmd-path);
+
uriEnv-name = tmp_virtual;
uriEnv-virtual = tmp_virtual;
+} else {
+/*
+ * The jk2_create_dir_config added an id to uri and path
+ * we have to correct it here.
+ */
+
+uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
+uri, cmd-path);
}
+
/* now lets actually add the parameter set in the Location block
*/
uriEnv-mbean-setAttribute(workerEnv-globalEnv, uriEnv-mbean,
(char *)name, (void *)val);
@@ -293,40 +304,46 @@
jk_uriEnv_t *child = (jk_uriEnv_t *)childv;
jk_uriEnv_t *parent = (jk_uriEnv_t *)parentv;
jk_uriEnv_t *winner = NULL;
-jk_uriEnv_t *loser = NULL;
+char *hostchild;
+char *hostparent;
if (child == NULL || child-uri == NULL || child-workerName ==
NULL) {
winner = parent;
-loser = child;
}
else if (parent == NULL || parent-uri == NULL
|| parent-workerName == NULL) {
winner = child;
-loser = parent;
/* interresting bit... so far they are equal ... */
}
else if (strlen(parent-uri) strlen(child-uri)) {
winner = parent;
-loser = child;
+}
+else if (strlen(parent-uri) == strlen(child-uri)) {
+/* Try the virtual host to decide */
+hostchild = child-mbean-getAttribute(workerEnv-globalEnv,
child-mbean,host);
+hostparent = parent-mbean-getAttribute(workerEnv-globalEnv,
parent-mbean,host);
+if (hostchild == NULL)
+winner = parent;
+if (hostparent == NULL)
+winner = child;
+if (winner == NULL) {
+if (strlen(hostchild) strlen(hostparent))
+winner = child;
+else
+winner = parent;
+}
}
else {
winner = child;
-loser = parent;
}
/* Do we merge loser into winner - i.e. inherit properties ? */
-/*if ( winner == child )
- fprintf(stderr, Going with the child\n);
- else if ( winner == parent )
- fprintf(stderr, Going with the parent\n);
- else
- fprintf(stderr, Going with NULL\n);
- */
-fprintf(stderr, Merging %s %s %s\n,
-(winner == NULL || winner-uri == NULL) ? : winner-uri,
+ap_log_perror(APLOG_MARK, APLOG_DEBUG, 0, NULL,
+ mod_jk2 Merging %s %s winner: %s\n,
(child == NULL || child-uri == NULL) ? : child-uri,
-(parent == NULL || parent-uri == NULL) ? :
parent-uri);
+(parent == NULL || parent-uri == NULL) ? : parent-uri,
+(winner == child) ? parent : child );
return (void *)winner;
-
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: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Good morning All.
In considering the duplication issue mentioned previously, it would seem
entirely possible that a specific uri could be given in both
workers2.properties and via a JkUriSet entry... therefore shouldn't the
JkUriSet function resolve the name to be used for a uri object and first
check for a matching object before creating another one? If the object
already exists then only 'non-key' properties such as 'info', 'servlet',
'worker' and so on, should be updated by JkUriSet on the existing obect.
Thinking out loud.
Norm
Good morning All.
Just tried Jean's recent change to mod_jk2.c and _pleased_ to say JkUriSet
now registers correctly the same as a [uri] section, and can access /admin
with only a Location in the httpd.conf. I did note there were duplicate
uri objects created (based on their name) if the same uri spec was in both
files, but in any case this is a lot closer to theory than in the past.
Thanks Jean.
Norm
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 12:22 AM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2
mod_jk2.c
jfclere 2004/03/31 06:22:04
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
Fix handling of id added in jk2_create_dir_config().
I do not see why we need this id... May because jk2_merge_dir_config()
was buggy.
That fixes PR 18472 and 28916.
Revision ChangesPath
1.82 +33 -16
jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- mod_jk2.c 21 Mar 2004 09:44:30 - 1.81
+++ mod_jk2.c 31 Mar 2004 14:22:04 - 1.82
@@ -221,14 +221,25 @@
strcpy(tmp_full_url, s-server_hostname);
strcat(tmp_full_url, uriEnv-uri);
}
+
uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
uri, tmp_full_url);
uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
path, cmd-path);
+
uriEnv-name = tmp_virtual;
uriEnv-virtual = tmp_virtual;
+} else {
+/*
+ * The jk2_create_dir_config added an id to uri and path
+ * we have to correct it here.
+ */
+
+uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
+uri, cmd-path);
}
+
/* now lets actually add the parameter set in the Location
block
*/
uriEnv-mbean-setAttribute(workerEnv-globalEnv, uriEnv-mbean,
(char *)name, (void *)val);
@@ -293,40 +304,46 @@
jk_uriEnv_t *child = (jk_uriEnv_t *)childv;
jk_uriEnv_t *parent = (jk_uriEnv_t *)parentv;
jk_uriEnv_t *winner = NULL;
-jk_uriEnv_t *loser = NULL;
+char *hostchild;
+char *hostparent;
if (child == NULL || child-uri == NULL || child-workerName ==
NULL) {
winner = parent;
-loser = child;
}
else if (parent == NULL || parent-uri == NULL
|| parent-workerName == NULL) {
winner = child;
-loser = parent;
/* interresting bit... so far they are equal ... */
}
else if (strlen(parent-uri) strlen(child-uri)) {
winner = parent;
-loser = child;
+}
+else if (strlen(parent-uri) == strlen(child-uri)) {
+/* Try the virtual host to decide */
+hostchild = child-mbean-getAttribute(workerEnv-globalEnv,
child-mbean,host);
+hostparent =
parent-mbean-getAttribute(workerEnv-globalEnv,
parent-mbean,host);
+if (hostchild == NULL)
+winner = parent;
+if (hostparent == NULL)
+winner = child;
+if (winner == NULL) {
+if (strlen(hostchild) strlen(hostparent))
+winner = child;
+else
+winner = parent;
+}
}
else {
winner = child;
-loser = parent;
}
/* Do we merge loser into winner - i.e. inherit properties ? */
-/*if ( winner == child )
- fprintf(stderr, Going with the child\n);
- else if ( winner == parent )
- fprintf(stderr, Going with the parent\n);
- else
- fprintf(stderr, Going with NULL\n);
- */
-fprintf(stderr, Merging %s %s %s\n,
-(winner == NULL || winner-uri == NULL) ? :
winner-uri,
+ap_log_perror(APLOG_MARK, APLOG_DEBUG,
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
[EMAIL PROTECTED] wrote:
jfclere 2004/03/31 06:22:04
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
Fix handling of id added in jk2_create_dir_config().
Please review I spent time to find why we added the id to path and uri but
now I do not understand why we added it.
I do not see why we need this id... May because jk2_merge_dir_config()
was buggy.
Now it uses the virtualhost length to decide between parent and child when the
two uris have the same length.
That fixes PR 18472 and 28916.
Revision ChangesPath
1.82 +33 -16jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- mod_jk2.c 21 Mar 2004 09:44:30 - 1.81
+++ mod_jk2.c 31 Mar 2004 14:22:04 - 1.82
@@ -221,14 +221,25 @@
strcpy(tmp_full_url, s-server_hostname);
strcat(tmp_full_url, uriEnv-uri);
}
+
uriEnv-mbean-setAttribute(workerEnv-globalEnv, uriEnv-mbean,
uri, tmp_full_url);
uriEnv-mbean-setAttribute(workerEnv-globalEnv, uriEnv-mbean,
path, cmd-path);
+
uriEnv-name = tmp_virtual;
uriEnv-virtual = tmp_virtual;
+} else {
+/*
+ * The jk2_create_dir_config added an id to uri and path
+ * we have to correct it here.
+ */
+
+uriEnv-mbean-setAttribute(workerEnv-globalEnv, uriEnv-mbean,
+uri, cmd-path);
}
+
/* now lets actually add the parameter set in the Location block */
uriEnv-mbean-setAttribute(workerEnv-globalEnv, uriEnv-mbean,
(char *)name, (void *)val);
@@ -293,40 +304,46 @@
jk_uriEnv_t *child = (jk_uriEnv_t *)childv;
jk_uriEnv_t *parent = (jk_uriEnv_t *)parentv;
jk_uriEnv_t *winner = NULL;
-jk_uriEnv_t *loser = NULL;
+char *hostchild;
+char *hostparent;
if (child == NULL || child-uri == NULL || child-workerName == NULL) {
winner = parent;
-loser = child;
}
else if (parent == NULL || parent-uri == NULL
|| parent-workerName == NULL) {
winner = child;
-loser = parent;
/* interresting bit... so far they are equal ... */
}
else if (strlen(parent-uri) strlen(child-uri)) {
winner = parent;
-loser = child;
+}
+else if (strlen(parent-uri) == strlen(child-uri)) {
+/* Try the virtual host to decide */
+hostchild = child-mbean-getAttribute(workerEnv-globalEnv, child-mbean,host);
+hostparent = parent-mbean-getAttribute(workerEnv-globalEnv, parent-mbean,host);
+if (hostchild == NULL)
+winner = parent;
+if (hostparent == NULL)
+winner = child;
+if (winner == NULL) {
+if (strlen(hostchild) strlen(hostparent))
+winner = child;
+else
+winner = parent;
+}
}
else {
winner = child;
-loser = parent;
}
/* Do we merge loser into winner - i.e. inherit properties ? */
-/*if ( winner == child )
- fprintf(stderr, Going with the child\n);
- else if ( winner == parent )
- fprintf(stderr, Going with the parent\n);
- else
- fprintf(stderr, Going with NULL\n);
- */
-fprintf(stderr, Merging %s %s %s\n,
-(winner == NULL || winner-uri == NULL) ? : winner-uri,
+ap_log_perror(APLOG_MARK, APLOG_DEBUG, 0, NULL,
+ mod_jk2 Merging %s %s winner: %s\n,
(child == NULL || child-uri == NULL) ? : child-uri,
-(parent == NULL || parent-uri == NULL) ? : parent-uri);
+(parent == NULL || parent-uri == NULL) ? : parent-uri,
+(winner == child) ? parent : child );
return (void *)winner;
-
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: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Good morning All.
Just tried Jean's recent change to mod_jk2.c and _pleased_ to say JkUriSet
now registers correctly the same as a [uri] section, and can access /admin
with only a Location in the httpd.conf. I did note there were duplicate
uri objects created (based on their name) if the same uri spec was in both
files, but in any case this is a lot closer to theory than in the past.
Thanks Jean.
Norm
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 12:22 AM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2
mod_jk2.c
jfclere 2004/03/31 06:22:04
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
Fix handling of id added in jk2_create_dir_config().
I do not see why we need this id... May because jk2_merge_dir_config()
was buggy.
That fixes PR 18472 and 28916.
Revision ChangesPath
1.82 +33 -16
jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- mod_jk2.c 21 Mar 2004 09:44:30 - 1.81
+++ mod_jk2.c 31 Mar 2004 14:22:04 - 1.82
@@ -221,14 +221,25 @@
strcpy(tmp_full_url, s-server_hostname);
strcat(tmp_full_url, uriEnv-uri);
}
+
uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
uri, tmp_full_url);
uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
path, cmd-path);
+
uriEnv-name = tmp_virtual;
uriEnv-virtual = tmp_virtual;
+} else {
+/*
+ * The jk2_create_dir_config added an id to uri and path
+ * we have to correct it here.
+ */
+
+uriEnv-mbean-setAttribute(workerEnv-globalEnv,
uriEnv-mbean,
+uri, cmd-path);
}
+
/* now lets actually add the parameter set in the Location block
*/
uriEnv-mbean-setAttribute(workerEnv-globalEnv, uriEnv-mbean,
(char *)name, (void *)val);
@@ -293,40 +304,46 @@
jk_uriEnv_t *child = (jk_uriEnv_t *)childv;
jk_uriEnv_t *parent = (jk_uriEnv_t *)parentv;
jk_uriEnv_t *winner = NULL;
-jk_uriEnv_t *loser = NULL;
+char *hostchild;
+char *hostparent;
if (child == NULL || child-uri == NULL || child-workerName ==
NULL) {
winner = parent;
-loser = child;
}
else if (parent == NULL || parent-uri == NULL
|| parent-workerName == NULL) {
winner = child;
-loser = parent;
/* interresting bit... so far they are equal ... */
}
else if (strlen(parent-uri) strlen(child-uri)) {
winner = parent;
-loser = child;
+}
+else if (strlen(parent-uri) == strlen(child-uri)) {
+/* Try the virtual host to decide */
+hostchild = child-mbean-getAttribute(workerEnv-globalEnv,
child-mbean,host);
+hostparent = parent-mbean-getAttribute(workerEnv-globalEnv,
parent-mbean,host);
+if (hostchild == NULL)
+winner = parent;
+if (hostparent == NULL)
+winner = child;
+if (winner == NULL) {
+if (strlen(hostchild) strlen(hostparent))
+winner = child;
+else
+winner = parent;
+}
}
else {
winner = child;
-loser = parent;
}
/* Do we merge loser into winner - i.e. inherit properties ? */
-/*if ( winner == child )
- fprintf(stderr, Going with the child\n);
- else if ( winner == parent )
- fprintf(stderr, Going with the parent\n);
- else
- fprintf(stderr, Going with NULL\n);
- */
-fprintf(stderr, Merging %s %s %s\n,
-(winner == NULL || winner-uri == NULL) ? : winner-uri,
+ap_log_perror(APLOG_MARK, APLOG_DEBUG, 0, NULL,
+ mod_jk2 Merging %s %s winner: %s\n,
(child == NULL || child-uri == NULL) ? : child-uri,
-(parent == NULL || parent-uri == NULL) ? :
parent-uri);
+(parent == NULL || parent-uri == NULL) ? : parent-uri,
+(winner == child) ? parent : child );
return (void *)winner;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
NormW wrote: Good morning All. Just tried Jean's recent change to mod_jk2.c and _pleased_ to say JkUriSet now registers correctly the same as a [uri] section, and can access /admin with only a Location in the httpd.conf. I did note there were duplicate uri objects created (based on their name) if the same uri spec was in both files, but in any case this is a lot closer to theory than in the past. Thanks Jean. Norm This code update will need many testings, and if no problem are found, I suggest a quick 2.0.5 release. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
[EMAIL PROTECTED] wrote:
jfclere 2004/03/12 05:47:20
Modified:jk/native2/server/apache13 mod_jk2.c
jk/native2/server/apache2 mod_jk2.c
Log:
Fix PR 27627: It was possible to core the httpd process.
Henri fixes the core... But I think we should return 400 otherwise jsp code
could be displayed as text.
Someone should take care of jk_dsapi_plugin.c and jk_isapi_plugin.c and do the same.
Note only Apache has been fixed but jk_dsapi_plugin.c and jk_isapi_plugin.c
probably have the same problem.
Revision ChangesPath
1.32 +11 -2 jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c
Index: mod_jk2.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- mod_jk2.c 24 Feb 2004 08:44:42 - 1.31
+++ mod_jk2.c 12 Mar 2004 13:47:20 - 1.32
@@ -573,6 +573,8 @@
jk_uriMap_t *uriMap;
char *name=NULL;
int n;
+const char *ptr;
+
if(r-proxyreq) {
return DECLINED;
}
@@ -597,8 +599,15 @@
/* get_env() */
env = workerEnv-globalEnv-getEnv( workerEnv-globalEnv );
+ptr = ap_get_server_name(r);
+if ( strlen(ptr) 1024 - 12 ) {
+/* That is probably an invalid request, DECLINED could display jsp source code. */
+env-l-jkLog(env, env-l, JK_LOG_DEBUG,
+ jk2_map_to_storage Host too big %s\n, ptr);
+return HTTP_BAD_REQUEST;
+}
uriEnv = workerEnv-uriMap-mapUri(env, workerEnv-uriMap,
- ap_get_server_name(r),
+ ptr,
ap_get_server_port(r),
r-uri);
1.76 +10 -2 jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -r1.75 -r1.76
--- mod_jk2.c 10 Mar 2004 09:39:30 - 1.75
+++ mod_jk2.c 12 Mar 2004 13:47:20 - 1.76
@@ -810,6 +810,7 @@
{
jk_uriEnv_t *uriEnv;
jk_env_t *env;
+const char *ptr;
if (r-proxyreq || workerEnv==NULL) {
return DECLINED;
@@ -822,8 +823,15 @@
/* From something like [uri:/examples/STAR] in workers2.properties */
env = workerEnv-globalEnv-getEnv( workerEnv-globalEnv );
+ptr = ap_get_server_name(r);
+if ( strlen(ptr) 1024 - 12 ) {
+/* That is probably an invalid request, DECLINED could display jsp source code. */
+env-l-jkLog(env, env-l, JK_LOG_DEBUG,
+ jk2_map_to_storage Host too big %s\n, ptr);
+return HTTP_BAD_REQUEST;
+}
uriEnv=workerEnv-uriMap-mapUri(env, workerEnv-uriMap,
-ap_get_server_name(r),
+ptr,
ap_get_server_port(r),
r-uri);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
-Original Message- From: jean-frederic clere Henri fixes the core... But I think we should return 400 otherwise jsp code could be displayed as text. Someone should take care of jk_dsapi_plugin.c and jk_isapi_plugin.c and do the same. jk_isapi_plugin uses INTERNET_MAX_URL_LENGTH which is 32 + 4 + 2048 bytes long. Do we need to limit that to 1012 bytes? Is there any RFC saying what is the longest SERVER_NAME? MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Mladen Turk wrote: -Original Message- From: jean-frederic clere Henri fixes the core... But I think we should return 400 otherwise jsp code could be displayed as text. Someone should take care of jk_dsapi_plugin.c and jk_isapi_plugin.c and do the same. jk_isapi_plugin uses INTERNET_MAX_URL_LENGTH which is 32 + 4 + 2048 bytes long. Do we need to limit that to 1012 bytes? 1024 is the size we have in jk_uriMap.c (:1234567890\0 makes the 12). Is there any RFC saying what is the longest SERVER_NAME? I have looked in RFC2616 - There is nothing about the length. MT. signature.asc Description: OpenPGP digital signature
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
[EMAIL PROTECTED] wrote:
jfclere 2004/03/03 09:55:32
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
Remove jk2_translate... It is still not 100% OK:
- LocationMatch does not work.
- Some _not_found ends in Tomcat when using mod_dav.
That is still not OK. I will go on later. Sorry :-(
Revision ChangesPath
1.72 +27 -30jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.71
retrieving revision 1.72
diff -u -r1.71 -r1.72
--- mod_jk2.c 3 Mar 2004 09:15:48 - 1.71
+++ mod_jk2.c 3 Mar 2004 17:55:31 - 1.72
@@ -42,7 +42,6 @@
*/
static int dirCounter=0;
-
#define JK_HANDLER (jakarta-servlet2)
#define JK_MAGIC_TYPE (application/x-jakarta-servlet2)
@@ -662,9 +661,11 @@
int rc1;
uriEnv=ap_get_module_config( r-request_config, jk2_module );
+if (uriEnv==NULL)
+ uriEnv=ap_get_module_config( r-per_dir_config, jk2_module );
/* not for me, try next handler */
-if(uriEnv==NULL || strcmp(r-handler,JK_HANDLER))
+if(uriEnv==NULL || !strcmp(r-handler,JK_HANDLER))
return DECLINED;
/* If this is a proxy request, we'll notify an error */
@@ -854,38 +855,35 @@
/* bypass the directory_walk and file_walk for non-file requests */
static int jk2_map_to_storage(request_rec *r)
{
-jk_uriEnv_t *uriEnv=ap_get_module_config( r-request_config, jk2_module );
-
-if( uriEnv != NULL ) {
-
-/* First find just the name of the file, no directory */
-r-filename = (char *)apr_filepath_name_get(r-uri);
+jk_uriEnv_t *uriEnv;
+jk_env_t *env;
-/* Only if sub-request for a directory, most likely from mod_dir */
-if (r-main r-main-filename
-!*apr_filepath_name_get(r-main-filename)){
-
-/* The filename from the main request will be set to what should
- * be picked up, aliases included. Tomcat will need to know about
- * those aliases or things won't work for them. Normal files
- * should be fine. */
-
-/* Need absolute path to stat */
-if (apr_filepath_merge(r-filename,
- r-main-filename, r-filename,
- APR_FILEPATH_SECUREROOT |
- APR_FILEPATH_TRUENAME,
- r-pool)
-!= APR_SUCCESS){
- return DECLINED; /* We should never get here, very bad */
-}
+if (r-proxyreq || workerEnv==NULL) {
+return DECLINED;
+}
+
+/* From something like [uri:/examples/STAR] in workers2.properties */
+env = workerEnv-globalEnv-getEnv( workerEnv-globalEnv );
+uriEnv=workerEnv-uriMap-mapUri(env, workerEnv-uriMap,
+ap_get_server_name(r),
+ap_get_server_port(r),
+r-uri);
-/* Stat the file so that mod_dir knows it's there */
-apr_stat(r-finfo, r-filename, APR_FINFO_TYPE, r-pool);
+if (uriEnv!=NULL uriEnv-workerName != NULL) {
+ap_set_module_config( r-request_config, jk2_module, uriEnv );
+r-handler=JK_HANDLER;
+workerEnv-globalEnv-releaseEnv( workerEnv-globalEnv, env );
+
+/* This could be a sub-request, possibly from mod_dir */
+if(r-main){
+ap_set_module_config( r-main-request_config, jk2_module, uriEnv );
+r-main-handler=JK_HANDLER;
}
return OK;
}
+
+workerEnv-globalEnv-releaseEnv( workerEnv-globalEnv, env );
return DECLINED;
}
@@ -897,7 +895,6 @@
/* Force the mpm to run before us and set the scoreboard image */
ap_hook_child_init(jk2_child_init, NULL, NULL, APR_HOOK_LAST);
-ap_hook_translate_name(jk2_translate, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_map_to_storage(jk2_map_to_storage, NULL, NULL, APR_HOOK_MIDDLE);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 22, 2002 4:51 AM
/* As per Servlet spec, do exact match first */
match=jk2_uriMap_exactMap( env, uriMap,
ctxEnv-exactMatch, uri, uriLen, reverse );
-if( match != NULL ) {
+if( match != NULL
+(( match-virtual==NULL hostEnv-virtual==NULL ) ||
+ ( hostEnv-virtual!=NULL
strcasecmp(match-virtual,hostEnv-virtual)==0 ))
+ ) {
Each uri shoud allready be in the right ctxEnv (look at uriMap init
phase).
Each vhost is a separate context with it's own match tables.
Don't think this is the correct patch.
+
uriEnv = workerEnv-uriMap-mapUri(env, workerEnv-uriMap,
-r-server-is_virtual ?
r-server-server_hostname : NULL,
+
apr_psprintf(r-pool,%s:%d,r-hostname,r-server-port),
r-uri );
Using r-hostname is correct, but not appending the :port
Should be something like (from mod_proxy) this:
if (r-hostname != NULL)
return r-hostname;
/* Set url to the first char after scheme:// */
if ((url = strchr(r-uri, ':')) == NULL
|| url[1] != '/' || url[2] != '/')
return NULL;
MT.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
I agree that my patch is buggy in the case of a request coming from 80
or 443, but if we want to support port bases V hosting, we need to pass
it down, if not
[uri:www.something.com:8080/somecontext]
Definitely will not work (this not works now i.e).. so to pass the port
as part of the hostname is needed when port is different from 80 and
443..
FOr the other 2 the is_virtual and the changes inside the mapper..
The initial idea was to do what isapi_redirector from jk does right now,
in jk i_r.dll there are 2 types of mappings:
1) globals ( for all VS and Default ) and
2) particular ( for a concrete VS or Default )
This needs to do 2 passes for the mapper, one for the particular
mappings with host+port ( if not 80 or 443 ) as vhost, and if none found
other for the Global mappings with NULL as vhost.. that is what isapi
does..
For the mapper, i was trying to need only one pass in the mapper, but
after looking at the code, it was buggy, as VS request from a registered
vhost, never will be mapped to anything outside of that vhost, so it's
need to do the two passes..
So my grandtotal for my first commits after months is 2 bugs in 2
commits, nice startup, thanks Mladen.. ;)
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: 22 de septiembre de 2002 11:36
Para: [EMAIL PROTECTED]
Asunto: cvs commit:
jakarta-tomcat-connectors/jk/native2/server/apache2
mod_jk2.c
mturk 2002/09/22 02:35:46
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
Cannot use the hostname:server_port cause the port is 0 for all
host:80 requests. Also is_virtual is used for separating default and
virtual hosts. In case of default server host the hostname provided
to uriMap _MUST_ be NULL to be able to map the default uri:/
Revision ChangesPath
1.52 +2 -2
jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/
mod_jk2.c,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- mod_jk2.c 22 Sep 2002 02:50:42 - 1.51
+++ mod_jk2.c 22 Sep 2002 09:35:46 - 1.52
@@ -679,7 +679,7 @@
*/
uriEnv = workerEnv-uriMap-mapUri(env, workerEnv-uriMap,
-
apr_psprintf(r-pool,%s:%d,r-hostname,r-server-port),
+r-server-is_virtual ? r-hostname : NULL,
r-uri );
if( uriEnv== NULL || uriEnv-workerName == NULL) {
--
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/native2/server/apache2 mod_jk2.c
-Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] I agree that my patch is buggy in the case of a request coming from 80 or 443, but if we want to support port bases V hosting, we need to pass it down, if not [uri:www.something.com:8080/somecontext] Definitely will not work (this not works now i.e).. so to pass the port as part of the hostname is needed when port is different from 80 and 443.. I agree to that. I know that neither my patch is perfect, but... We can use the sheme://hostname[:port] parsing but that has to go in the server part of the connector. The apache will give you same r-hostname no matter what the port number is. I was thinking to make those vhost mappings more like uri mappings. Like: [uri:vhost1:*] Will map all the port numbers so we can even use the port 0 (default one). Or more selective [uri:vhost1:8080] Will map only the 8080 port of the vhost1 1) globals ( for all VS and Default ) and 2) particular ( for a concrete VS or Default ) This needs to do 2 passes for the mapper, one for the particular mappings with host+port ( if not 80 or 443 ) as vhost, and if none found other for the Global mappings with NULL as vhost.. that is what isapi does.. Yes, but this will need to change the init phase not the map phase. If we provide the hostname to the uriMap it has to map that vhost. Global mappings should explicitly be defined, not assumed, because you will not be able to differentiate default and virtual hosts. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: 21 de septiembre de 2002 11:45 +uriEnv = workerEnv-uriMap-mapUri(env, workerEnv-uriMap, +r-server-is_virtual ? r-server-server_hostname : NULL, +r-uri ); I think this should use r-hostname+r-server-port instead of r-server-server_hostname only, to match exactly what apache does..the check r-server-is_virtual is not correct also.. must be the mapper who do the work of guess which is the appropiate action for some uri instead of forcing the default host if not a virtual server.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting [EMAIL PROTECTED]: On 22 Jul 2002, Bojan Smojver wrote: If there is no physical file, then nothing will get done by the patch at all (since r-finfo.filetype is 0). It won't affect mod_dir's old behaviour at all. I'm not sure how that changes things... My question was: if you have a precompiled index.jsp, there will be no file - only a servlet-map with uri=/index.jsp and the servlet name. DirectoryIndex will not find index.jsp, and will assume there is no index - and serve the dir. Which is wrong. Which is how it used to be in the old code anyway. And that means that DirectoryIndex should not be used if you don't have physical files in the right places (with the current patch level in mod_jk 1.2.x for Apache 2) or in virtual places (with the future code, that you're proposing, which will be capable of asking TC about such files). The indexes as defined by the servlet spec may be real files or virtual (mapped) resources. I guess I was aiming at this: - if all files are physical and local, then mod_dir and DirectoryIndex are fine and make sense If you can make sure that all paths are checked for both static and mapped resources - yes, you can use mod_dir. OK, if you want to write something along those lines, I have no problems with that. It's best of both worlds in that case. I'm guessing that you'd have to ask TC if there are files out there that match, right? Because this is not a real request (not in jk_map_to_storage() anyway), but 'what if', jk_handler() doesn't get called, so it would have to be done in some other way. - if all files are not physical and local, mod_dir and DirectoryIndex don't make sense and should not be used I don't think this is an issue we should discuss - this case is already solved, if no files on the apache machine there is nothing we can do but forward. The lb case is also not an issue - if there are local static files, apache can serve them - and dynamic resources are handled by tomcat lb. That sounds good to me. Bojan PS. Note that mod_jk 1.2.0 doesn't use DocumentRoot as the base for the request any more (that was clearly a bug). I fixed that this morning. I have not done any changes to mod_jk2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting [EMAIL PROTECTED]: You don't need to ask tomcat - jk should have all the mappings, and it can already map any URI. All it has to do is: - for each index: -- concatenate with the current uri -- do the jk mapping ( or internal redirect if you use Location instead of the internal mapper ). If a match is found - forward to tomcat. -- check if a file exists. If yes - serve it as static ( since we already checked all servlet mappings ). - if no match is found, use mod_dir to display the directory. But in the short term, I think we should just let tomcat deal with that, until we have the fix. Are you referring here to mod_jk2 only or both mod_jk 1.2.0 and mod_jk2? Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting [EMAIL PROTECTED]: Are you referring here to mod_jk2 only or both mod_jk 1.2.0 and mod_jk2? I think it could be done for jk2 ( but not easy ). I'm not sure about 1.2 - just forwarding and letting tomcat handle it is not the worse thing. How about I try to fix it properly in mod_jk 1.2.0 and let you guys do whatever you like in mod_jk2? Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting [EMAIL PROTECTED]: You don't need to ask tomcat - jk should have all the mappings, and it can already map any URI. All it has to do is: - for each index: -- concatenate with the current uri -- do the jk mapping ( or internal redirect if you use Location instead of the internal mapper ). If a match is found - forward to tomcat. -- check if a file exists. If yes - serve it as static ( since we already checked all servlet mappings ). - if no match is found, use mod_dir to display the directory. Just reading the algorithm and thinking about the implementation of it. Some of the things might present themselves as big problems here in relation to servlet mappings... An example configuration: DirectoryIndex index.jsp index.vm The order of events would be: 1. mod_dir does a sub request for index.jsp 2. jk_map_to_storage() receives the request 3. jk_map_to_storage() engages map_uri_to_worker() -- this would be new code 4. map_uri_to_worker() finds nothing because it has no mapping to anything that matches *.jsp Now, the next step is rather tricky and is the key to the whole thing. Does jk_map_to_storage(): a) assume that there is index.jsp in one of the mappings that match the URI minus the filename; jk_map_to_storage() could be very wrong about this - maybe there is a default file there, but not index.jsp - this would then result in a failed request b) continue processing with the next index file (in this case index.vm) and possibly miss both index.jsp and index.vm in one of the servlet mappings Keep in mind that these are sub-requests that don't actually result in the file being served. It's just mod_dir's way of checking what would happen if there was a file like that 'in the file system'. So, one cannot 'go back' and do all this again, unless mod_dir is changed to do this kind of thing twice (which is definitely a bad idea). I actually think that it is not possible to establish if there is such a file, unless mod_jk somehow knows about their exisitence. I'm not all that familir with mappings, but I reckon that isn't the case. And then, when everybody thought all was lost... ;-) If my old kludge is applied (with the correct test this time) to jk_handler(), things might be better. The kludge involved jk_handler() responding not just to JK_HANDLER requests but also to DIR_MAGIC_TYPE requests. Now, jk_handler() would find the mapping (since the request is for a directory, not a file) and the request would be served by Tomcat. Would this work? I think it might... Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
- Original Message - From: Bojan Smojver [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, July 21, 2002 9:19 PM Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c Quoting [EMAIL PROTECTED]: You don't need to ask tomcat - jk should have all the mappings, and it can already map any URI. All it has to do is: - for each index: -- concatenate with the current uri -- do the jk mapping ( or internal redirect if you use Location instead of the internal mapper ). If a match is found - forward to tomcat. -- check if a file exists. If yes - serve it as static ( since we already checked all servlet mappings ). - if no match is found, use mod_dir to display the directory. Just reading the algorithm and thinking about the implementation of it. Some of the things might present themselves as big problems here in relation to servlet mappings... An example configuration: DirectoryIndex index.jsp index.vm The order of events would be: 1. mod_dir does a sub request for index.jsp 2. jk_map_to_storage() receives the request 3. jk_map_to_storage() engages map_uri_to_worker() -- this would be new code 4. map_uri_to_worker() finds nothing because it has no mapping to anything that matches *.jsp Now, the next step is rather tricky and is the key to the whole thing. Does jk_map_to_storage(): a) assume that there is index.jsp in one of the mappings that match the URI minus the filename; jk_map_to_storage() could be very wrong about this - maybe there is a default file there, but not index.jsp - this would then result in a failed request b) continue processing with the next index file (in this case index.vm) and possibly miss both index.jsp and index.vm in one of the servlet mappings Keep in mind that these are sub-requests that don't actually result in the file being served. It's just mod_dir's way of checking what would happen if there was a file like that 'in the file system'. So, one cannot 'go back' and do all this again, unless mod_dir is changed to do this kind of thing twice (which is definitely a bad idea). I actually think that it is not possible to establish if there is such a file, unless mod_jk somehow knows about their exisitence. I'm not all that familir with mappings, but I reckon that isn't the case. And then, when everybody thought all was lost... ;-) If my old kludge is applied (with the correct test this time) to jk_handler(), things might be better. The kludge involved jk_handler() responding not just to JK_HANDLER requests but also to DIR_MAGIC_TYPE requests. Now, jk_handler() would find the mapping (since the request is for a directory, not a file) and the request would be served by Tomcat. Would this work? I think it might... At the moment, the servlet-mapping issue is somewhat of a red-herring, since only 3.3.2-dev supports it (and even there, it is disabled by default). For now, mod_jk(2) might as well assume that the physical jsp/vm file is there, since Tomcat requires that it is. The real issue is that jk_map_to_storage was a kludgy attempt to bypass tree-walking by Apache (and save the time to do all of those stat calls). Your fix at least removes the kludgy part. ;-) I *really* don't like the idea of passing DIR_MAGIC_TYPE requests to Tomcat, since I tend to set up directories with only static content that only Apache knows about. Sending them to Tomcat just gives me very many 404 errors, so I'd be forced to use a branched copy of mod_jk. If you have: JkMount /myapp/*.jsp ajp13 JkMount /myapp/*.vm ajp13 Then jk_translate will grab the request for /myapp/index.jsp and set the handler. If the file is physically there, then jk_map_to_storage will stat it, and everyone is happy. Otherwise, jk_translate will grab the request for /myapp/index.vm and set the handler and do the same check for a physical file. In Apache 1.3.x, this is basically what happens except that the physical file test is done by Apache's tree-walk. Bojan -- 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/native2/server/apache2 mod_jk2.c
Quoting [EMAIL PROTECTED]: DirectoryIndex index.jsp index.vm The order of events would be: 1. mod_dir does a sub request for index.jsp 2. jk_map_to_storage() receives the request 3. jk_map_to_storage() engages map_uri_to_worker() -- this would be new code 4. map_uri_to_worker() finds nothing because it has no mapping to anything that matches *.jsp That's actually a problem - map_uri_to_worker would find a match ( using *.jsp extension mapping ). Sorry, I meant, but never wrote, that the problem would be if there was no explicit extension mapping. If there was, the match would be found and that wouldn't be one of the problem cases because we'd simulate r-finfo.filetype by setting it explicitly to APR_REG. Then mod_dir would engage the real request based on that with handler set to JK_HANDLER, which would then call Tomcat. Now, the next step is rather tricky and is the key to the whole thing. Does jk_map_to_storage(): a) assume that there is index.jsp in one of the mappings that match the URI minus the filename; jk_map_to_storage() could be very wrong about this - maybe there is a default file there, but not index.jsp - this would then result in a failed request If jk_map_to_storage finds an exact or prefix mapping - then the problem is solved, the request goes to tomcat. Well, yes, but at this stage we are not doing the request. mod_dir is just checking if the request should go there or not. And since the real request would be originated by mod_dir, which filename would mod_dir use: index.jsp or index.vm? That would be a real problem case, I think. If it finds an extension mapping - I have no idea. If it doesn't find any mapping - then it's not a request for tomcat and you can look for static files ( or let mod_dir do it ). So, one cannot 'go back' and do all this again, unless mod_dir is changed to do this kind of thing twice (which is definitely a bad idea). No, you don't need to go back. For each attempted index you make a subrequest and you need to determine if tomcat could handle it. You mean here like this? Following code from mod_dir: --- rr = ap_sub_req_lookup_uri(name_ptr, r, NULL); --- Wouldn't that just end up going through jk_map_to_storage() again? If my old kludge is applied (with the correct test this time) to jk_handler(), things might be better. The kludge involved jk_handler() responding not just to JK_HANDLER requests but also to DIR_MAGIC_TYPE requests. Now, jk_handler() would find the mapping (since the request is for a directory, not a file) and the request would be served by Tomcat. I think this would work and is the best short-term solution. If it is a DIR, let tomcat serve it for now. I can implement that easily. But there is one catch: static files would get checked first (through the code in jk_map_to_storage()) and if the match wasn't found (either because there is no DirecoryIndex or there were no physical files that Apache can find), the the raw directory would hit jk_handler(). Is that a problem? Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting Bill Barker [EMAIL PROTECTED]: I *really* don't like the idea of passing DIR_MAGIC_TYPE requests to Tomcat, since I tend to set up directories with only static content that only Apache knows about. Sending them to Tomcat just gives me very many 404 errors, so I'd be forced to use a branched copy of mod_jk. Actually, DIR_MAGIC_TYPE would *only* get involved if there was no match found through my current code jk_map_to_storage(), and that would not be the case if: - you defined DirectoryIndex - there is a physical file that Apache can stat Basically, static files would be preferred (I don't like the idea of involving Tomcat if I don't need to either). Does that eliminate the objection? Bojan PS. I have applied ap_is_directory() call in the latest version of the patch. Do you think I should have stuck with determining if the r-main-filename ends in a '/'? It would save some stat-ing, but on the other hand I'm not sure if file system directories are stored in Unix format or architecture dependent format (i.e. with '\' on Windows). I wanted to make sure I don't run into problems on Windows... If someone can verify that it'll be a '/', then I think I should remove that stat and just use the last character verification. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
My apologies everyone... Just ignore the part of my previous e-mail marked here with between the stars. It just plain stupid :-( ** Quoting Bojan Smojver [EMAIL PROTECTED]: Quoting [EMAIL PROTECTED]: DirectoryIndex index.jsp index.vm The order of events would be: 1. mod_dir does a sub request for index.jsp 2. jk_map_to_storage() receives the request 3. jk_map_to_storage() engages map_uri_to_worker() -- this would be new code 4. map_uri_to_worker() finds nothing because it has no mapping to anything that matches *.jsp That's actually a problem - map_uri_to_worker would find a match ( using *.jsp extension mapping ). Sorry, I meant, but never wrote, that the problem would be if there was no explicit extension mapping. If there was, the match would be found and that wouldn't be one of the problem cases because we'd simulate r-finfo.filetype by setting it explicitly to APR_REG. Then mod_dir would engage the real request based on that with handler set to JK_HANDLER, which would then call Tomcat. Now, the next step is rather tricky and is the key to the whole thing. Does jk_map_to_storage(): a) assume that there is index.jsp in one of the mappings that match the URI minus the filename; jk_map_to_storage() could be very wrong about this - maybe there is a default file there, but not index.jsp - this would then result in a failed request If jk_map_to_storage finds an exact or prefix mapping - then the problem is solved, the request goes to tomcat. Well, yes, but at this stage we are not doing the request. mod_dir is just checking if the request should go there or not. And since the real request would be originated by mod_dir, which filename would mod_dir use: index.jsp or index.vm? That would be a real problem case, I think. If it finds an extension mapping - I have no idea. If it doesn't find any mapping - then it's not a request for tomcat and you can look for static files ( or let mod_dir do it ). So, one cannot 'go back' and do all this again, unless mod_dir is changed to do this kind of thing twice (which is definitely a bad idea). No, you don't need to go back. For each attempted index you make a subrequest and you need to determine if tomcat could handle it. You mean here like this? Following code from mod_dir: --- rr = ap_sub_req_lookup_uri(name_ptr, r, NULL); --- Wouldn't that just end up going through jk_map_to_storage() again? ** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[BUGS: 9913, 10789] Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
I've looked through Mark's excellent analysis of the problem (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10789) and I also played with changing the hook order for mod_jk 1.2.0. Are you sure this actually fixes the thing? My experience from 1.2.0 is similar to Mark's with 2.x - the handler never gets called because the r-handler is DIR_MAGIC_TYPE, not JK_HANDLER. So, I think Mark's code would be the real fix for both - giving Apache a hint that the handler is JK_HANDLER. My original 'fix' (more like a kludge) for 1.2.0 doesn't do that. It waits for the next round, accepts the DIR_MAGIC_TYPE call, where r-uri isn't the correct file (i.e. it is not /some/path/index.jsp), but rather a directory (/some/path/), which then causes havoc down the line in getServletPath(). Tomcat 3.3.x is smart and it corrects that for JSP's. I'm not sure if TC 4.x does that at all (I have seen at least one other report related to bug 9913 with TC 4.x where my 'fix' didn't actually fix the problem - some fix :-). Mladen, what's your take on all this? Do you have a setup handy to verify that the changing of hook ordering fixed the problem in mod_jk2? Mark, does the fix in mod_jk2 work in your environment? Bojan PS. Sorry guys, this one is *really* bugging me... Quoting [EMAIL PROTECTED]: mturk 2002/07/18 08:15:00 Modified:jk/native2/server/apache2 mod_jk2.c Log: Fix the bug 10789 caused by hook order. Revision ChangesPath 1.42 +3 -3 jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c Index: mod_jk2.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- mod_jk2.c 17 Jul 2002 22:43:58 - 1.41 +++ mod_jk2.c 18 Jul 2002 15:15:00 - 1.42 @@ -724,8 +724,8 @@ ap_hook_handler(jk2_handler, NULL, NULL, APR_HOOK_MIDDLE); ap_hook_post_config(jk2_post_config,NULL,NULL,APR_HOOK_MIDDLE); ap_hook_child_init(jk2_child_init,NULL,NULL,APR_HOOK_MIDDLE); -ap_hook_translate_name(jk2_translate,NULL,NULL,APR_HOOK_FIRST); -ap_hook_map_to_storage(jk2_map_to_storage, NULL, NULL, APR_HOOK_MIDDLE); + ap_hook_translate_name(jk2_translate,NULL,NULL,APR_HOOK_MIDDLE); +ap_hook_map_to_storage(jk2_map_to_storage, NULL, NULL, APR_HOOK_FIRST); } module AP_MODULE_DECLARE_DATA jk2_module = -- 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: [BUGS: 9913, 10789] Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
On Fri, 19 Jul 2002 13:57:22 +1000 (EST), Bojan Smojver wrote:
: My experience from 1.2.0 is similar to Mark's with 2.x - the handler never gets
: called because the r-handler is DIR_MAGIC_TYPE, not JK_HANDLER. So, I think
: Mark's code would be the real fix for both - giving Apache a hint that the
: handler is JK_HANDLER.
:
: ...
:
: Mladen, what's your take on all this? Do you have a setup handy to verify that
: the changing of hook ordering fixed the problem in mod_jk2?
:
: Mark, does the fix in mod_jk2 work in your environment?
I was just getting ready to post something saying the fix seems to break
mod_jk2 altogether for me.
For one thing, I think, if jk2_map_to_storage is invoked before
jk2_translate then mod_jk2 is going to return DECLINED all the time.
Which is what I am seeing. Nothing gets sent over to tomcat.
For example:
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples
request_rec:009D79A8
Return DECLINED
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples/
request_rec:009D79A8
Return DECLINED
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples/index.html
request_rec:009D59A0
Return DECLINED
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples/index.jsp
request_rec:009D59A0
Return DECLINED
jk2_handler( )ENTER
Unparsed uri: /tomcat/examples/
request_rec:009D79A8
uriEnv:
Return DECLINED
In jk2_map_to_storage the start of the code is:
jk_uriEnv_t *uriEnv=ap_get_module_config( r-request_config, jk2_module );
if( uriEnv != NULL ) {
but the only calls to
ap_set_module_config( r-request_config, jk2_module, uriEnv );
are in jk2_translate.
So, it seems to me that jk2_translate needs to be invoked before
jk2_map_to_storage. Which is what I thought the original order was.
But I have to confess I really do not understand APR_HOOK_MIDDLE,
APR_HOOK_FIRST, etc..
Anyhow, the bottom line is that on my machine doing a clean and then
rebuilding tomcat and mod_jk2 using the latest jakarta-tomcat-connectors
from cvs, leaves me with mod_jk2 not sending anything on to tomcat.
--
Mark Miesfeld
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [BUGS: 9913, 10789] Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting Mark Miesfeld [EMAIL PROTECTED]:
I was just getting ready to post something saying the fix seems to
break mod_jk2 altogether for me.
Interesting. I haven't actually checked explicit calls to pages with reversed
order and mod_jk 1.2.0, so I don't really know if that breaks it or not. Will
test tonight (Sydney time).
For one thing, I think, if jk2_map_to_storage is invoked before
jk2_translate then mod_jk2 is going to return DECLINED all the time.
Which is what I am seeing. Nothing gets sent over to tomcat.
For example:
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples
request_rec:009D79A8
Return DECLINED
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples/
request_rec:009D79A8
Return DECLINED
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples/index.html
request_rec:009D59A0
Return DECLINED
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples/index.jsp
request_rec:009D59A0
Return DECLINED
jk2_handler( )ENTER
Unparsed uri: /tomcat/examples/
request_rec:009D79A8
uriEnv:
Return DECLINED
In jk2_map_to_storage the start of the code is:
jk_uriEnv_t *uriEnv=ap_get_module_config( r-request_config,
jk2_module );
if( uriEnv != NULL ) {
but the only calls to
ap_set_module_config( r-request_config, jk2_module, uriEnv );
are in jk2_translate.
So, it seems to me that jk2_translate needs to be invoked before
jk2_map_to_storage. Which is what I thought the original order was.
But I have to confess I really do not understand APR_HOOK_MIDDLE,
APR_HOOK_FIRST, etc.
I don't really understand Apache all that well, but the API documentation talks
about 'Controlling hook calling order'. From 'Apache Hook Functions' document:
...all modules using HOOK_FIRST will run before the HOOK_MIDDLE which are
before HOOK_LAST. If the order is unimportant, HOOK_MIDDLE is recommended.
Anyhow, the bottom line is that on my machine doing a clean and then
rebuilding tomcat and mod_jk2 using the latest
jakarta-tomcat-connectors
from cvs, leaves me with mod_jk2 not sending anything on to tomcat.
OK. I'll try your solution with mod_jk 1.2.0 and mod_jk2 people might do the
same. I don't really like my fix in 1.2.0 because it's just a cheap hack and it
doesn't address the root cause of the problem
The reason why it didn't work in mod_jk2 is the fact that the test was wrong. It
should have been:
---
if((uriEnv==NULL || strcmp(r-handler,JK_HANDLER))
strcmp(r-handler,DIR_MAGIC_TYPE)))
return DECLINED;
---
But even that probably wouldn't work with TC 4.x because getServletPath() would
start returning strange things. I think your approach is much better.
Bojan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
