tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: mod_jk doesn't map to software-generated web address, but maps to this address when I enter it into browser
Date Fri, 17 Feb 2012 16:38:20 GMT

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

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 and 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
and 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:

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" <> 
To: "Tomcat Users List" <> 
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 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: 
Based on your description below, Apache webserver would select the first virtual host 
with that name. In this case, the first VirtualHost section below would not match 
(since does not match 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 * 
<VirtualHost *> 

I suggest that you re-read the Apache documentation about these, 
here : 
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,
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). 

introduces a family of 
that answers only on the interface that has as an IP address, and only on port 80

(on which Apache is supposedly listening). 


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 *: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, is Apache going to 
try matching the ServerName's in the <VirtualHost> sections (because the IP

matches), or in the <VirtualHost *> sections (because the "*" also matches the IP

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: 
For additional commands, e-mail: 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message