RE: Does anyone care....
OK... I will put the jk2 connector on my development machine and merge the changes at my next opportunity. Thanks again for your help. .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226 -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 6:54 PM To: 'Tomcat Developers List' Subject: RE: Does anyone care Steven, JK2 is aproaching Stable state at very good pace, and the help there is much more needed than in jk1, testing and reporting bugs, and implemeting features like yours, is preferred.. in any case yours is ok for jk1.. thought.. in to jk2. Do you think it's better to do this sooner or later? I think sooner the better, mostly i can easily test to your changes in my dev machine ;), and development in jk2 ( native2 ) it's active at the moment, and jk1 it's freezed .. soo With respect to your last comment: Is submitting patches as incidents in bugzilla preferred to posting them on the mailing list? If so, I will do this in the future. Well, you finally seemed to the get the answer by yourself :), but for sure a bug with a [PATCH] in the summary and a good explanation, with the patch attached will do well too, i prefer it, it gets stored ata safe place ( much better than a mail archive ) and we can add comments for posterity.. and the bugzilla mails go to the tomcat-dev too.. so better to add a it as bug.. IMHO.. Thank you very much. Thank you for your patience Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Does anyone care....
... about the IIS connector? Every post that I have made with respect to it has been more or less ignored over the last couple of weeks. First when I reported the problem and asked for advice on how I might implement a solution. Then when I implemented a solution without advice and posted the patch, and most recently when I asked about the suitability and status of my patch. What do I have to do to get some support? I'm willing to follow any protocol that is required... I would just appreciate not having to apply my patch every time I upgrade the connector to the latest official version. Thanks .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226
RE: Does anyone care....
Ignacio, Thanks for the reply. I'm sorry that my e-mail sounded a bit edgy, but I felt it had to be that way to get some info back. I know that people can get busy at times (I did not know the state of your personal work load at the moment) so take your time. I was mostly concerned about not getting any info about where the review process was, but you have now answered that question, and I thank you. As far as JK1 vs. JK2 goes, is the JK2 connector ready? I seem to remember reading some docs in the source tree generally stating that since the jk2 stuff is not as seasoned as the jk1 stuff, an upgrade is not recommended for production systems so I am sticking with jk1. What is/will be the benefit of switching? Whenever it is felt that the connector is ready for mass use, I will be upgrading. I will also be willing to merge my changes in to jk2. Do you think it's better to do this sooner or later? With respect to your last comment: Is submitting patches as incidents in bugzilla preferred to posting them on the mailing list? If so, I will do this in the future. Thank you very much. .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226 -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 4:29 PM To: 'Tomcat Developers List' Subject: RE: Does anyone care Steven, I normally do care of the IIS connector, sorry for not being quick but as everyone i'm overloaded, your change althought optional is big and until yesterday i did not reviewed it, and i'll plan to apply it asap.. If someone can take it and apply, ok from me, but as everybody here apply something without at least compiling and testing it makes me very nervous, and i suppouse other committers feel the same.. ... about the IIS connector? Every post that I have made with respect to it has been more or less ignored over the last couple of weeks. First when I reported the problem and asked for advice on how I might implement a solution. Then when I implemented a solution without advice and posted the patch, and most recently when I asked about the suitability and status of my patch. Nothing cares about your problems mainly because they are you problems, you are the most interested in them, sooo :).. the real reason is that the IIS connector in his old jk1 version is only touched by a small subset of committers, me in between them, and we all are very very busy atm, sorry.., but that's life.. What do I have to do to get some support? I'm willing to follow any protocol that is required... I would just appreciate not having to apply my patch every time I upgrade the connector to the latest official version. Steven, the jk1 IIS connector it's freezed from many many time ago.. so it cannot be that hard to follow the development.. ;) and you have learned the protocol very well, maybe a bug with the patch as an attachment could do the trick ;).. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Patch submission status.
Is the patch that I submitted for the iis connector under consideration? It has been a while and I have not seen a commit notice with those changes. If I need to make any modifications, please let me know. Thanks .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226
[PATCH] Fixing Interoperability problem in iis connector
SHALL
*
* THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY
*
* DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
*
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
*
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
*
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
*
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
*
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
*
* POSSIBILITY OF SUCH DAMAGE.
*
*
*
* =
*
*
*
* This software consists of voluntary contributions made by many indivi-
*
* duals on behalf of the Apache Software Foundation. For more information
*
* on the Apache Software Foundation, please see http://www.apache.org/.
*
*
*
* =
*/
/***
* Description: Utilities to to keep track of request information *
* Author: Steven Velez [EMAIL PROTECTED]*
* Version: $Revision: $ *
***/
#ifndef REQ_INFO_H
#define REQ_INFO_H
#include jk_pool.h
#include jk_logger.h
#ifdef __cpluplus
extern C
{
#endif
/*
* The information 'class' that will store information
* for a particular request. This information will be set in the filter
* and read in the extension.
*/
struct _request_information
{
/* The name of the worker selected by the filter.
* Relaces TOMCATWORKER: */
char *worker_name;
/* The uri of the original request.
* Replaces TOMCATURI: */
char *uri;
/* The query string of the original request.
* Replaces TOMCATQUERY: */
char *query_string;
/** For keeping track of the various allocations of member data */
jk_pool_t p;
jk_pool_atom_t buff[BIG_POOL_SIZE];
};
typedef struct _request_information request_information_t;
typedef unsigned long request_info_name_t;
#define REQUEST_INFO_ERR_NAME (0)
/* Management functions to intialize and destroy a global request info map
*/
int rinfo_init_map(jk_logger_t *log);
int rinfo_close_map();
/* Insert a request information object in the map */
request_info_name_t rinfo_map_insert(request_information_t * ri);
/* Find the request information object related to the given request.
* This function returns 'NULL' if the object can not be found */
request_information_t *rinfo_map_at(request_info_name_t req);
/* Find the requwst information object related to the give request.
* This function will also remove the object from the map. */
request_information_t *rinfo_map_remove_at(request_info_name_t req);
/* utility function to append a request info name to a uri
* the return value of the function is a pointer to the caller-supplied
* buffer */
char *rinfo_append_name_to_uri(char *uri, request_info_name_t req,
char *buff, size_t size);
/* Utiltity function to retreive a request info name from
* a query string */
request_info_name_t rinfo_name_from_query(char *query);
/* Object lifetime management functions... these should be used to
* create and destroy a request_info object */
request_information_t *rinfo_new();
void rinfo_delete(request_information_t * ri);
/* functions to set data in the request info object. These functions
* duplicate the parameters, so it will remain the responsibility of
* the caller to manage the memory pointed to in the second parameter. */
void rinfo_set_worker(request_information_t * ri, char *name);
void rinfo_set_uri(request_information_t * ri, char *uri);
void rinfo_set_query_string(request_information_t * ri, char *qs);
/* functions to access data in the request info object.
* They return poitners to internal buffers, so callers should not
manipulate
* them directly. */
char *rinfo_get_worker(request_information_t * ri);
char *rinfo_get_uri(request_information_t * ri);
char *rinfo_get_query_string(request_information_t * ri);
#ifdef __cplusplus
}
#endif
#endif
File: /home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/req_info.c
/* =
*
*
*
* The Apache Software License, Version 1.1
*
*
*
* Copyright (c) 1999-2001 The Apache Software Foundation.
*
* All rights reserved.
*
*
*
* =
*
*
*
* Redistribution and use in source and binary forms, with or without modi-
*
* fication, are permitted provided that the following conditions are met:
*
*
*
* 1. Redistributions of source code must retain the above copyright notice
RE: [PATCH] Fixing Interoperability problem in iis connector
:( My mail client warpped the code inappropriately.. I will remedy this and re-post. Thanks, Steven -Original Message- From: Steven Velez [mailto:svelez;alventive.com] Sent: Tuesday, November 12, 2002 12:12 PM To: 'Tomcat Developers List' Subject: [PATCH] Fixing Interoperability problem in iis connector I have noticed problems in the Jakarta tomcat IIS connector when it is used in conjunction with Netegrity's SiteMinder web agent. The following patch works-around the problem by giving the user the option of passing data between the filter and the extension using shared memory instead of headers. The changes include two new files and I could not include them in the CVS diff since I could not add the files to the repository so I have in-lined them and hopefully appropriately delimited them. ..Patch deleted...
RE: [PATCH] Fixing Interoperability problem in iis connector
NEGLIGENCE OR OTHERWISE) ARISING IN
*
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
*
* POSSIBILITY OF SUCH DAMAGE.
*
*
*
* =
*
*
*
* This software consists of voluntary contributions made by many indivi-
*
* duals on behalf of the Apache Software Foundation. For more information
*
* on the Apache Software Foundation, please see http://www.apache.org/.
*
*
*
* =
*/
/***
* Description: Utilities to to keep track of request information *
* Author: Steven Velez [EMAIL PROTECTED]*
* Version: $Revision: $ *
***/
#ifndef REQ_INFO_H
#define REQ_INFO_H
#include jk_pool.h
#include jk_logger.h
#ifdef __cpluplus
extern C
{
#endif
/*
* The information 'class' that will store information
* for a particular request. This information will be set in the filter
* and read in the extension.
*/
struct _request_information
{
/* The name of the worker selected by the filter.
* Relaces TOMCATWORKER: */
char *worker_name;
/* The uri of the original request.
* Replaces TOMCATURI: */
char *uri;
/* The query string of the original request.
* Replaces TOMCATQUERY: */
char *query_string;
/** For keeping track of the various allocations of member data */
jk_pool_t p;
jk_pool_atom_t buff[BIG_POOL_SIZE];
};
typedef struct _request_information request_information_t;
typedef unsigned long request_info_name_t;
#define REQUEST_INFO_ERR_NAME (0)
/* Management functions to intialize and destroy a global request info map
*/
int rinfo_init_map(jk_logger_t *log);
int rinfo_close_map();
/* Insert a request information object in the map */
request_info_name_t rinfo_map_insert(request_information_t * ri);
/* Find the request information object related to the given request.
* This function returns 'NULL' if the object can not be found */
request_information_t *rinfo_map_at(request_info_name_t req);
/* Find the requwst information object related to the give request.
* This function will also remove the object from the map. */
request_information_t *rinfo_map_remove_at(request_info_name_t req);
/* utility function to append a request info name to a uri
* the return value of the function is a pointer to the caller-supplied
* buffer */
char *rinfo_append_name_to_uri(char *uri, request_info_name_t req,
char *buff, size_t size);
/* Utiltity function to retreive a request info name from
* a query string */
request_info_name_t rinfo_name_from_query(char *query);
/* Object lifetime management functions... these should be used to
* create and destroy a request_info object */
request_information_t *rinfo_new();
void rinfo_delete(request_information_t * ri);
/* functions to set data in the request info object. These functions
* duplicate the parameters, so it will remain the responsibility of
* the caller to manage the memory pointed to in the second parameter. */
void rinfo_set_worker(request_information_t * ri, char *name);
void rinfo_set_uri(request_information_t * ri, char *uri);
void rinfo_set_query_string(request_information_t * ri, char *qs);
/* functions to access data in the request info object.
* They return poitners to internal buffers, so callers should not
manipulate
* them directly. */
char *rinfo_get_worker(request_information_t * ri);
char *rinfo_get_uri(request_information_t * ri);
char *rinfo_get_query_string(request_information_t * ri);
#ifdef __cplusplus
}
#endif
#endif
File: /home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/req_info.c
/* =
*
*
*
* The Apache Software License, Version 1.1
*
*
*
* Copyright (c) 1999-2001 The Apache Software Foundation.
*
* All rights reserved.
*
*
*
* =
*
*
*
* Redistribution and use in source and binary forms, with or without modi-
*
* fication, are permitted provided that the following conditions are met:
*
*
*
* 1. Redistributions of source code must retain the above copyright notice
*
*notice, this list of conditions and the following disclaimer.
*
*
*
* 2. Redistributions in binary form must reproduce the above copyright
*
*notice, this list of conditions and the following disclaimer in the
*
*documentation and/or other materials provided with the distribution.
*
*
*
* 3. The end-user documentation included with the redistribution, if any,
*
*must include the following acknowlegement
RE: [PATCH] Fixing Interoperability problem in iis connector
OK.. this time I sent a test before posting... and the post still has
problems it seems the list server (or something) is wrapping long
lines. how do I deal with this?
.-.| Steven Velez
oo|| Software Engineer
/`'\| alventive
(\_;/) | 678-202-2226
-Original Message-
From: Steven Velez [mailto:svelez;alventive.com]
Sent: Tuesday, November 12, 2002 12:23 PM
To: 'Tomcat Developers List'
Subject: RE: [PATCH] Fixing Interoperability problem in iis connector
This should, hopefully, be correctly formatted.
Index: isapi.dsp
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/isapi.dsp,v
retrieving revision 1.9
diff -u -r1.9 isapi.dsp
--- isapi.dsp 9 Apr 2002 23:06:52 - 1.9
+++ isapi.dsp 12 Nov 2002 16:58:07 -
@@ -170,6 +170,10 @@
SOURCE=..\common\jk_worker.c
# End Source File
+# Begin Source File
+
+SOURCE=.\req_info.c
+# End Source File
# End Group
# Begin Group Header Files
@@ -265,6 +269,10 @@
# Begin Source File
SOURCE=..\common\jk_worker.h
+# End Source File
+# Begin Source File
+
+SOURCE=.\req_info.h
# End Source File
# End Group
# Begin Group Resource Files
Index: jk_isapi_plugin.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c,v
retrieving revision 1.18
diff -u -r1.18 jk_isapi_plugin.c
--- jk_isapi_plugin.c 25 Sep 2002 00:49:40 - 1.18
+++ jk_isapi_plugin.c 12 Nov 2002 16:58:07 -
@@ -78,6 +78,8 @@
#include jk_worker.h
#include jk_uri_worker_map.h
+#include req_info.h
+
#define VERSION_STRING Jakarta/ISAPI/ JK_VERSTRING
#define DEFAULT_WORKER_NAME (ajp13)
@@ -109,6 +111,8 @@
#define URI_SELECT_UNPARSED_VERB(unparsed)
#define URI_SELECT_ESCAPED_VERB (escaped)
+#define SHMEM_REQUEST_INFO_TAG (use_shared_mem)
+
#define BAD_REQUEST-1
#define BAD_PATH -2
#define MAX_SERVERNAME 128
@@ -142,6 +146,17 @@
} \
}\
+#define GET_REQ_INFO_VALUE(ri, name, var) { \
+char *temp; \
+if (temp = rinfo_get_##name (ri)) \
+{ \
+(var) = jk_pool_strdup(private_data-p, temp); \
+} else { \
+(var) = NULL; \
+} \
+} \
+
+
static char ini_file_name[MAX_PATH];
static int using_ini_file = JK_FALSE;
static int is_inited = JK_FALSE;
@@ -159,6 +174,7 @@
static int log_level = JK_LOG_EMERG_LEVEL;
static char worker_file[MAX_PATH * 2];
static char worker_mount_file[MAX_PATH * 2];
+static int shmem_enabled = JK_FALSE;
#define URI_SELECT_OPT_PARSED 0
#define URI_SELECT_OPT_UNPARSED 1
@@ -670,6 +686,7 @@
char Host[INTERNET_MAX_URL_LENGTH]=;
char Port[INTERNET_MAX_URL_LENGTH]=;
char Translate[INTERNET_MAX_URL_LENGTH];
+char target_uri_buff[INTERNET_MAX_URL_LENGTH]=;
BOOL (WINAPI * GetHeader)
(struct _HTTP_FILTER_CONTEXT * pfc, LPSTR lpszName,
LPVOID lpvBuffer, LPDWORD lpdwSize );
BOOL (WINAPI * SetHeader)
@@ -681,6 +698,8 @@
DWORD szHost = sizeof(Host);
DWORD szPort = sizeof(Port);
DWORD szTranslate = sizeof(Translate);
+ request_information_t *p_request_info = NULL;
+request_info_name_t info_name = 0;
if (iis5) {
GetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)-GetHeader;
@@ -700,11 +719,13 @@
/*
* Just in case somebody set these headers in the request!
*/
-SetHeader(pfc, URI_HEADER_NAME, NULL);
-SetHeader(pfc, QUERY_HEADER_NAME, NULL);
-SetHeader(pfc, WORKER_HEADER_NAME, NULL);
-SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL);
-
+if (!shmem_enabled) {
+SetHeader(pfc, URI_HEADER_NAME, NULL);
+SetHeader(pfc, QUERY_HEADER_NAME, NULL);
+SetHeader(pfc, WORKER_HEADER_NAME, NULL);
+SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL);
+}
+
if (!GetHeader(pfc, url, (LPVOID)uri, (LPDWORD)sz)) {
jk_log(logger, JK_LOG_ERROR,
HttpFilterProc error while getting the url\n);
@@ -802,14 +823,30 @@
forwardURI = uri;
}
-if(!AddHeader(pfc, URI_HEADER_NAME, forwardURI) ||
- ( (query != NULL strlen(query) 0)
- ? !AddHeader(pfc, QUERY_HEADER_NAME, query) :
FALSE ) ||
- !AddHeader(pfc, WORKER_HEADER_NAME, worker) ||
- !SetHeader(pfc, url, extension_uri)) {
-jk_log(logger, JK_LOG_ERROR,
- HttpFilterProc error while adding request
headers\n);
-return SF_STATUS_REQ_ERROR;
+if (!shmem_enabled) {
+if(!AddHeader(pfc, URI_HEADER_NAME
IIS JK Connector.
I have run in to a problem using the JK (version 1) connector for IIS in conjunction with an ISAPI filter put out in closed source. Basically, this other filter randomly deletes request headers for some reason and that interrupts the communication between the filter and the extension that implement the JK connector. I was planning on working around this problem by passing request information from the filter to the extension using shared memory (using a lookup table and passing the index in the query string). However, I was wondering if the patch would be more likely to be accepted if the new mechanism was enabled via a configuration option (or compile setting) or if I could just go ahead make that the communication mechanism. Also, is there a place I can go to read the coding standards for Jakarta, C-language projects? Thanks Steven B. Velez Software Engineer alventive [EMAIL PROTECTED]
Case Sensitivity on Windows systems...
Hello All, This question really transcends the users list, but is not really completely development related, but please hear me out. I am using tomcat on a windows server, and I am accessing it through ajp from an IIS server. Now, for reasons that I will go in to if desired, I need to make my uri worker map case insensitive. Previously, I was using apache, entering my uris as lower case and using mod_rewrite to lowercase incoming urls. That is no longer an option and I am now stuck with IIS. Here is the development part if I were to add configurable functionality to the jk_isapi filter to lowercase urls before it sends them to the jk_isapi extension... would this change be accepted in the main code stream? My other thought would be to make the match case insensitive on windows platforms in jk_uri_worker_map.c file, but his is harder to make configurable and I think it would be less desirable for the general user. My final thought would be to create my own filter which lowercases the urls before jk_isapi can get to them ... and this accomplishes the purpose but is less desirable to me because it increases the number of deliverables for relatively little reason. So, which solution would be the most widely accepted by the tomcat developer community? Disclaimer: I have not looked at any of this in the 4.x stream, so if the issue is solved in some elegant way there, please point me to it. Many Thanks .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226
RE: Patch: Mod_jk remove query string as factor in MATCH_TYPE_EXACT
Hrmm, I 'm not sure the test you ran covered the case I found. In my case, I have a map defined as such: JkMount /postlogin.jsp ACDS_ajp when I point my browser to: http://myserver/postlogin.jsp?foo=barbaz=bunt then the mapping is not found. I tried to correct that with the patch I have submitted. .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226 -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 08, 2001 4:17 AM To: [EMAIL PROTECTED] Subject: Re: Patch: Mod_jk remove query string as factor in MATCH_TYPE_EXACT Steven Velez wrote: .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226 querystring.patchName: querystring.patch Type: unspecified type (application/octet-stream) Hi, I am confused what do you want to correct? The traces I have done all is ok: +++ [Wed Aug 08 10:02:28 2001] [jk_uri_worker_map.c (409)]: Into jk_uri_worker_map_t::map_uri_to_worker [Wed Aug 08 10:02:28 2001] [jk_uri_worker_map.c (426)]: Attempting to map URI '/examples/servlet/SessionExample' [Wed Aug 08 10:02:28 2001] [jk_uri_worker_map.c (440)]: jk_uri_worker_map_t::map_uri_to_worker, Found an exact match examples - /examples/servlet/SessionExample [Wed Aug 08 10:02:28 2001] [jk_worker.c (132)]: Into wc_get_worker_for_name examples [Wed Aug 08 10:02:28 2001] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Wed Aug 08 10:02:28 2001] [jk_ajp_common.c (1275)]: Into jk_worker_t::get_endpoint +++ Could it be an httpd problem? (I have tried with Apache-1.3.20). Cheers Jean-frederic
RE: Patch: Mod_jk remove query string as factor in MATCH_TYPE_EXACT
well, I was using Apache 1.3.19 for NT when I found the problem I believe and now I'm using 1.3.20. If it works without the patch, that's fine. I just couldn't get it to work for me and figured that the community would like the change. No biggie. .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226 -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 08, 2001 9:57 AM To: [EMAIL PROTECTED] Subject: Re: Patch: Mod_jk remove query string as factor in MATCH_TYPE_EXACT Steven Velez wrote: Hrmm, I 'm not sure the test you ran covered the case I found. In my case, I have a map defined as such: JkMount /postlogin.jsp ACDS_ajp when I point my browser to: http://myserver/postlogin.jsp?foo=barbaz=bunt then the mapping is not found. I tried to correct that with the patch I have submitted. Which httpd server do you use? I have tried with: http://vtxclere:8880/examples/jsp/num/numguess.jsp?guess=2 and JkMount /examples/jsp/num/numguess.jsp examples It works OK: +++ [Wed Aug 08 15:51:39 2001] [jk_uri_worker_map.c (409)]: Into jk_uri_worker_map_t::map_uri_to_worker [Wed Aug 08 15:51:39 2001] [jk_uri_worker_map.c (426)]: Attempting to map URI '/examples/jsp/num/numguess.jsp' [Wed Aug 08 15:51:39 2001] [jk_uri_worker_map.c (440)]: jk_uri_worker_map_t::map_uri_to_worker, Found an exact match examples - /examples/jsp/num/numguess.jsp[Wed Aug 08 15:51:39 2001] [jk_worker.c (132)]: Into wc_get_worker_for_name examples [Wed Aug 08 15:51:39 2001] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker +++ .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226 -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 08, 2001 4:17 AM To: [EMAIL PROTECTED] Subject: Re: Patch: Mod_jk remove query string as factor in MATCH_TYPE_EXACT Steven Velez wrote: .-.| Steven Velez oo|| Software Engineer /`'\| alventive (\_;/) | 678-202-2226 querystring.patchName: querystring.patch Type: unspecified type (application/octet-stream) Hi, I am confused what do you want to correct? The traces I have done all is ok: +++ [Wed Aug 08 10:02:28 2001] [jk_uri_worker_map.c (409)]: Into jk_uri_worker_map_t::map_uri_to_worker [Wed Aug 08 10:02:28 2001] [jk_uri_worker_map.c (426)]: Attempting to map URI '/examples/servlet/SessionExample' [Wed Aug 08 10:02:28 2001] [jk_uri_worker_map.c (440)]: jk_uri_worker_map_t::map_uri_to_worker, Found an exact match examples - /examples/servlet/SessionExample [Wed Aug 08 10:02:28 2001] [jk_worker.c (132)]: Into wc_get_worker_for_name examples [Wed Aug 08 10:02:28 2001] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Wed Aug 08 10:02:28 2001] [jk_ajp_common.c (1275)]: Into jk_worker_t::get_endpoint +++ Could it be an httpd problem? (I have tried with Apache-1.3.20). Cheers Jean-frederic
Patch: Mod_jk remove query string as factor in MATCH_TYPE_EXACT
Title: Patch: Mod_jk remove query string as factor in MATCH_TYPE_EXACT .-. | Steven Velez oo| | Software Engineer /`'\ | alventive (\_;/) | 678-202-2226 querystring.patch
