modjkl...@comcast.net wrote:
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.
Each of these permutations above can have the effect of "landing" upon a different
VirtualHost, depending on how /exactly/ your Apache configuration is put together (and
your DNS).
The way you showed earlier, there seemed to be a mixture of IP-based VirtualHost's and
name-based VirtualHost's, each one group with its own default VirtualHost.
Since we never saw the whole configuration, it is difficult to tell what
happened exactly.
We don't even know if the Adobe thing is sending proper HTTP 1.1 requests, with a correct
"Host:" header.
What Rainer told you to do, essentially has the effect that all JkMount/JkUnmount
directives are "centralised" (or "defaulted") in the part of the Apache configuration that
is outside of all <VirtualHost> sections. Along with the "JkMountCopy All", this causes
all these JkMount/JkUnmount to be copied to (or inherited by) /all/ the VirtualHosts
(including the default one(s)).
So this way, we are sure that no matter which VirtualHost is actually processing the Adobe
request, the appropriate JkMount is there for "/mywebapp".
In other words, no matter if the Adobe app sends a correct HTTP 1.1 request with the
correct "Host:" header, as long as it does connect to an IP address of your server on port
80, the request will encounter a VirtualHost which knows how to proxy "/mywebapp" to Tomcat.
This makes it work, but of course it also hides any "defect" of the Adobe thingy's
request, if any.
It also means that whichever (valid) hostname is used for a request to "/mywebapp", it
will work and end up in Tomcat's "mywebapp". This may be what you want, or it may not.
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.
Those are transmission errors at the TCP level. That packet should be repeated then
automatically, and this should not play a role here.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
