Hi Andre, yes I see your point (Rainer's solution would solve that too I suppose). Also, believe me, I was trying all sorts of addresses in Adobe's input field:
http://www.mydomain.com/mywebapp http://mydomain.com/mywebapp http://mydomain.com:80/mywebapp http://host3.mydomain.com/mywebapp http://host3.mydomain.com:80/mywebapp http://xx.xxx.xxx.xxx/mywebapp etc. practically every permutation I could think of, all with the same result. Also interesting is the tcpdump I send out earlier reports two cksum INCORRECTs when Adobe accesses port 80 (without Rainer's fix). No idea what's going on there. ----- Original Message ----- From: "André Warnier" <a...@ice-sa.com> To: "Tomcat Users List" <users@tomcat.apache.org> Sent: Thursday, February 16, 2012 10:46:45 AM Subject: Re: mod_jk doesn't map to software-generated web address, but maps to this address when I enter it into browser 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
