Thanks Andre, for taking time to type up the comments below (very helpful to
me, a new user). Rainer and Christopher, thanks as well for your recent
comments regarding this post. I did a quick Google search that shows Adobe
Flashbuilder uses HTTP/1.1, so that shouldn't be an issue.
Some more background -- I'm hosting with a company, perhaps like most, that
uses Cpanel to simplify their administration. One result is that the httpd.conf
file is auto-generated each night, and this process limits the changes one can
make to its contents. Unfortunately this means I'm unable to modify the
NameVirtualHost designations, nor the order of the the VirtualHost tags. Of the
4 VirtualHost tags I'm only able to modify the last two (which relate
specifically to mydomain.com and myotherdomain.com). Modifying the first two
VirtualHost tags would wreck havoc with the Cpanel and WHM processes and so
that's why they're autogenerated each night. Also, as Cpanel versions are
upgraded behind the scenes, changes to its distiller, etc., may change
httdp.conf to stay in synch with the new Cpanel version, although this
shouldn't change the user-modifications in the limited places where they are
allowed. I'm new to this, but it's probably nothing new to you. My point is,
the one thing I do have control over is placing mod_jk attributes globally in
httpd.conf as well as in its VirtualHost tags for mydomain.com and
myotherdomain.com. Ranier's comments therefore proved to work nicely in this
environment.
Inspired by this forum's help I've gained the courage to try to improve on this
process. I can see that a global JkMountCopy All would open quite a lot for web
crawlers to view, which I probably should avoid. So I've been tweaking various
settings on my client to map the Linux drive that Adobe Flashbuilder uses to
read/write files to the server, as well as the URL input field Adobe uses to
connect to the server. As I mentioned earlier, every change I make on those
fronts always produces a result in the mod_jk.log file that is:
host3.mydomain.com:/mywebapp/flex_wizard_project_test_script_server_550713325917236076.htm
It's possible (I'm thinking) that Adobe is using a different URL to access the
server than what appears in mod_jk.log. After several hours I managed to
stumble upon one setting that allowed me to remove the global JkMountCopy All
setting and use the intended VirtualHost JkMount's, although I'm not exactly
sure why (and so I am feeling quite lucky). To understand everything I'd need
to see the host name used in the post or get statements directly from Adobe's
software on the client. Not sure how to extract this directly but maybe there's
a specific tcpdump command that can show it (?). I need to dig into it more.
----- Original Message -----
From: "André Warnier" <a...@ice-sa.com>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Friday, February 17, 2012 12:13:33 AM
Subject: Re: mod_jk doesn't map to software-generated web address, but maps to
this address when I enter it into browser
modjkl...@comcast.net wrote:
> Thanks so much Andre for taking the time to help me understand this. It's
> VERY helpful! I've attached the section of httpd.conf below related to
> virtual hosts. I think I'm starting to get the picture now.
>
> Whatever I input into Adobe's software, I ALWAYS see in the mod_jk.log file
> the hostname: host3.mydomain.com.
Based on your description below, Apache webserver would select the first
virtual host
associated
with that name. In this case, the first VirtualHost section below would not
match
(since xx.xxx.xxx.196 does not match host3.mydomain.com). But I'm guessing the
2nd
VirtualHost section below DOES match
(since I interpret * to match anything).
No, you still misunderstand somewhat the meaning of
NameVirtualHost *
and
<VirtualHost *>
I suggest that you re-read the Apache documentation about these,
here : http://httpd.apache.org/docs/2.2/vhosts/name-based.html
but as a kind of shortcut explanation :
"NameVirtualHost *" introduces a "family" of name-based VirtualHost's.
<VirtualHost *> indicates that "this section" is a VirtualHost belonging to
that family "*".
The "*" is NOT what Apache matches on, when it compares to the request's
"Host:" header.
What Apache matches on, are the *ServerName* and *ServerAlias* values /inside/
the
<VirtualHost> section.
In that sense, the "*" in NameVirtualHost and <VirtualHost> is just a common
label, like
the "family name". If you change the "*" to for example "*:80", then you should
change it
in both the NameVirtualHost AND all corresponding <VirtualHost> lines. They
must always
match exactly.
In yet another way to say this :
NameVirtualHost *
introduces a family of
<VirtualHost *>
that answers on all the IP addresses of the server, and all ports on which
Apache listens
(as per the "Listen" directive(s)).
NameVirtualHost *:80
introduces a family of
<VirtualHost *:80>
that answers on all the IP addresses of the server, but only on port 80 (on
which Apache
is supposedly listening).
NameVirtualHost 1.2.3.4:80
introduces a family of
<VirtualHost 1.2.3.4:80>
that answers only on the interface that has 1.2.3.4 as an IP address, and only
on port 80
(on which Apache is supposedly listening).
etc..
In the vast majority of cases, you would want all your VirtualHost's to be
available on
all the interfaces of your server, and all ports on which Apache is
"Listen"-ing.
So you would use only
NameVirtualHost *
<VirtualHost *>
Only if you have a good reason, should you start "limiting" a family of
VirtualHost's to
only one specific IP address and/or port of the server.
And when you mix both, such as
NameVirtualHost 1.2.3.4:80
NameVirtualHost *:80
as you are doing, then it becomes more complicated to figure out in which order
Apache is
going to evaluate this in order to find a VirtualHost which matches a request.
For example, if a request comes in on the interface with IP 1.2.3.4, is Apache
going to
try matching the ServerName's in the <VirtualHost 1.2.3.4> sections (because
the IP
matches), or in the <VirtualHost *> sections (because the "*" also matches the
IP 1.2.3.4) ?
So don't do that unless you have a specific reason to do it.
This is fast becoming an Apache httpd forum...
On the other hand, it is rather important to understand these things, in order
to know
which JkMount applies to which host, which is at the root of your mod_jk
issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
