And still more..
André Warnier wrote:
Another addendum at end.
André Warnier wrote:
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.
Or perhaps, it is the way in which you are entering hostname in that
input box of the form, that confuses the Adobe thingy ?
Such as maybe :
- when you enter "host3.mydomain.com:8080", it understands that this is
a hostname
- but when you enter "host3.mydomain.com" it doesn't
Have you tried entering "host3.mydomain.com:80" ? or
"http://host3.mydomain.com"; ?
Actually, when I think about it, both Rainer's explanation and mine here may be
right.
If the Adobe thing gets confused, and does not use the correct hostname for sending its
request (say for example that it defaults to "localhost"), then we could have a mixture of
the wrong URI being processed by the wrong VirtualHost, and really confusing everything..
(The first defined VirtualHost in Apache becoming the default VirtualHost, used if the
hostname doesn't match..)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
