tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: mod_jk doesn't map to software-generated web address, but maps to this address when I enter it into browser
Date Thu, 16 Feb 2012 18:09:10 GMT
In this case, and although Rainer is of course The mod_jk specialist, I beg to differ with

his analysis.


modjklist@comcast.net wrote:
> 
> ------------mod_jk.log file snippet---------- 
> 
> [Thu Feb 16 06:46:37 2012] [13722:140020322740160] [debug] jk_handler::mod_jk.c (2662):
Service finished with status=404 for worker=worker1 
> 
> [Thu Feb 16 06:47:35 2012] [13723:140020322740160] [debug] jk_translate::mod_jk.c (3488):
missing uri map for host3.mydomain.com:/mywebapp/flex_wizard_project_test_script_server_550713325917236076.htm

> 
> RIGHT NOW THE ADOBE SOFTWARE WILL ATTEMPT TO CONNECT TO THE SERVER...
> 
> [Thu Feb 16 06:47:35 2012] [13723:140020322740160] [debug] jk_map_to_storage::mod_jk.c
(3647): missing uri map for host3.mydomain.com:/mywebapp/flex_wizard_project_test_script_server_550713325917236076.htm

> 
> NOTICE THE WEB ADDRESS ADOBE IS USING IN THE ABOVE LINE

Well no, actually it is not a web address.  It seems very much like Adobe is sending 
"host3.mydomain.com:/mywebapp/flex_w..."  AS A URI.
And since mod_jk has no mapping for a URI starting with "host3..", it says so and hands it

back to Apache.  From then on, we don't see anything anymore in the mod_jk log of course,

since it is Apache which is trying to match that URI (and failing).

> 
> [Thu Feb 16 06:47:35 2012] [13723:140020322740160] [debug] jk_translate::mod_jk.c (3488):
missing uri map for host3.mydomain.com:/404.shtml 
> 

That's again the Adobe thing trying now to get other documents, which similarly fail 
because there is still that funny prefix to the URI.
And so on...

> 
> IN THE NEXT LINE, I HAVE TAKEN ADOBES ADDRESS SEEN ABOVE AND ENTERED IT MANUALLY INTO
A BROWSER WINDOW
> 
> [Thu Feb 16 06:55:21 2012] [13725:140020322740160] [debug] map_uri_to_worker_ext::jk_uri_worker_map.c
(1036): Attempting to map URI '/mywebapp/flex_wizard_project_test_script_server_550713325917236076.htm'
from 6 maps 
> 
> [Thu Feb 16 06:55:21 2012] [13725:140020322740160] [debug] find_match::jk_uri_worker_map.c
(850): Attempting to map context URI '/mywebapp/*=worker1' source 'JkMount' 
> 
> [Thu Feb 16 06:55:21 2012] [13725:140020322740160] [debug] find_match::jk_uri_worker_map.c
(863): Found a wildchar match '/mywebapp/*=worker1'

Notice the difference ?  When you do this "manually", that "host3.." prefix is not there,

and the match succeeds.

> 
> [Thu Feb 16 06:55:21 2012] [13725:140020322740160] [debug] jk_handler::mod_jk.c (2522):
Into handler jakarta-servlet worker=worker1 r->proxyreq=0 
> 
> [Thu Feb 16 06:55:21 2012] [13725:140020322740160] [debug] wc_get_worker_for_name::jk_worker.c
(116): found a worker worker1 
> 
> IN THIS CASE, MOD_JK DOES CORRECTLY SEND THIS ADDRESS TO THE WEB CONTAINER FOR PROCESSING
(THE QUESTION OF THIS POST IS: WHY DIDN'T IT DO THIS WHEN ADOBE USED THE SAME ADDRESS ABOVE?)
> 

Well actually, I don't think that mod_jk has anything to do with the problem.
It seems to be the Adobe thing which gets things wrong.
When the request URI is fine, then mod_jk is doing its job.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message