In this case, and although Rainer is of course The mod_jk specialist, I beg to differ with
his analysis.
modjkl...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
