tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: mod_jk doesn't map to software-generated web address, but maps to this address when I enter it into browser
Date Thu, 16 Feb 2012 20:24:11 GMT
modjklist@comcast.net wrote:
> Thanks Andre, 
> 
> I'd still be interested is there's a way to have mod_jk only check for traffic coming
into mydomain.com for folder /mywebapp. I think the current solution checks all domains, such
as mydomain2.com and mydomain3.com, etc., for a map to mydomain.com/mywebapp. 
> 
> Couldn't I just have all those JkMounts defined globally, then within the VirtualHost
tags for mydomain.com, include a "JkMountCopy On"? But that didn't work for me so I must be
approaching this wrong.
> 

Yes, you should be able to do that.  But it then again depends on whether the Adobe thing

is really sending the request in the proper way.  Which right now we don't know, but which

you may be able to verify using your packet dump.
If it does not send the requests properly, then you will end up with the same problem as 
before : requests not ending up in the <VirtualHost> which you expect, and this unexpected

VirtualHost knowing nothing about a mapping for "/mywebapp".

A correct request should have at least 2 lines such as

line 1 :
GET /mywebapp/... HTTP/1.1    (could also be POST instead of GET)
then:
.. (any number of header lines, 0-n)
then:
Host: the.correct.hostname
.. (any number of header lines, 0-n)
..an empty line (CR/LF)

In the first GET or POST line, after the GET or POST it should start with "/mywebapp", 
without any other prefix.
In the Host: line, there should be the hostname which you expect.
If this is not the case, then something is wrong in the Adobe client.

If the Adobe client sends proper requests, then you can try :

- remove the "JkMountCopy All" from you main configuration
- move each JkMount line inside the <VirtualHost> where it should take effect (copying

them to several <VirtualHost>'s if that is what you want)
- define your VirtualHost's as follows :

In the main configuration part :

Listen 80
...
NameVirtualHost *:80          # (1)
...

<VirtualHost *:80>            # (must match (1) exactly)
   Servername localhost
   D0ocumentRoot /something/harmless
</VirtualHost>

<VirtualHost *:80>            # (must match (1) exactly)
   Servername host.mydomain.com
.. JkMount's for this VirtualHost
</VirtualHost>

etc..

This way :
- there are only name-based VirtualHost's
- the first one is the "default host", used when a request comes in which does not match 
any ServerName (for example requests sent by devious robots looking for "/phpmyadmin" and

the like)
- the others will be used each by requests whose Host: header exactly match their 
ServerName or ServerAlias

But again, check the Adobe requests first, otherwise you could get in trouble again.

Variation :
If it turns out that most of your JkMount's do need to be copied into most of your 
VirtualHosts, then
- still remove the JkMountCopy All
- leave the "common" JkMount's in the main config part
- put a "JkMountCopy On" in each VirtualHost that should get a copy of these common ones
- add the specific JkMount's to each VirtualHost



> ----- Original Message ----- 
> From: "André Warnier" <aw@ice-sa.com> 
> To: "Tomcat Users List" <users@tomcat.apache.org> 
> Sent: Thursday, February 16, 2012 11:41:25 AM 
> Subject: Re: mod_jk doesn't map to software-generated web address, but maps to this address
when I enter it into browser 
> 
> modjklist@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-unsubscribe@tomcat.apache.org 
> For additional commands, e-mail: users-help@tomcat.apache.org 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message