Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Subject: Re: Apache mod_jk connector question about alias
To: users@tomcat.apache.org
References: <64dd71ce-5593-31cb-fad0-63e9fc4576c6@marcchamberlin.com>
 <761fe44b-0724-ba16-0918-4f182dc71123@kippdata.de>
 <0f2caf20-aae6-7f22-9745-70d8256d57ee@marcchamberlin.com>
 <24b9b80c-a5cb-68e3-1318-2af41b2bdfd9@christopherschultz.net>
 <58089A4D.1010308@ice-sa.com>
 <23c9f1e9-e798-fa48-4f37-fe6ad29a53a1@marcchamberlin.com>
 <4b921db2-61e2-3b70-13d4-54e93d919e3e@christopherschultz.net>
From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat=29?= <aw@ice-sa.com>
Message-ID: <58090C81.7080909@ice-sa.com>
Date: Thu, 20 Oct 2016 20:27:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <4b921db2-61e2-3b70-13d4-54e93d919e3e@christopherschultz.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
archived-at: Thu, 20 Oct 2016 18:27:26 -0000

On 20.10.2016 18:23, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Marc,
>
> On 10/20/16 11:34 AM, Marc Chamberlin wrote:
>> On 10/20/2016 3:19 AM, André Warnier (tomcat) wrote:
>>> On 20.10.2016 01:58, Christopher Schultz wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>
>>>> Marc,
>>>>
>>>> On 10/18/16 7:59 PM, Marc Chamberlin wrote:
>>>>> On 10/17/2016 10:36 AM, Rainer Jung wrote:
>>>>>>
>>>>>> Alias maps URIs to local file system directories. JkMount
>>>>>> maps URIs to remote back end requests.
>>>>>>
>>>>>> You can not change JkMount forwarding using Alias (except
>>>>>> that if you have a comflict between Alias and JkMount only
>>>>>> one of them wins).
>>>>>>
>>>>>> As far as I understand you are not really trying to map
>>>>>> requests to the local web server file system, but instead
>>>>>> want to forward to a Tomcat back end but change the URI
>>>>>> path which is used when accessing Apache to something else
>>>>>> being used to acces Tomcat. E.g. the URI
>>>>>> /jsp-examples/something gets used when accessing Apache and
>>>>>> mod_jk should send this request as /examples/jsp/something
>>>>>> to the Tomcat back end.
>>>>>>
>>>>>> If you really need to change URIs, then often mod_proxy is
>>>>>> much easier to set up, because it has specific directives
>>>>>> for this (ProxyPass etc.).
>>>>>>
>>>>>> With mod_jk you would first need to use mod_rewrite
>>>>>> RewriteRules to change the URI, and then JkMount to forward
>>>>>> them. More details can be found at
>>>>>>
>>>>>> http://tomcat.apache.org/connectors-doc/common_howto/proxy.html#UR
> L%2
>>>>
>>>>>>
> 0Rewriting
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> The rest of this docs page might be useful as well.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Rainer
>>>>>>
>>>>> Thanks a million Rainer, you got me over that hump! I have
>>>>> it working now but have another question - When the response
>>>>> is generated for a request, that used the alias in the URL,
>>>>> is there a way to keep the client browser from displaying
>>>>> what the alias got mapped to?
>>>>>
>>>>> So for example, if I use the alias in the URL -
>>>>> http://www.mydomain.com/jsp-examples  that I send to the
>>>>> Apache server, and it in turn forwards that request to Tomcat
>>>>> as http://www.mydomain.com/examples/jsp, I would prefer that
>>>>> the response, sent back to the user, contains the original,
>>>>> aliased or unaliased, version of the URL that he/she typed,
>>>>> and not just the resolved version. As it stands I am always
>>>>> getting the response URL of
>>>>> http://www.mydomain.com/examples/jsp displayed in the client
>>>>> browser.
>>>>>
>>>>> What follows is my current version of the config file that I
>>>>> am using for the jsp-examples. Seems to be working mostly OK,
>>>>> so hopefully I am on the right track. FYI - I intend to
>>>>> include these config files in various virtual hosts
>>>>> configurations each of which have their own document root,
>>>>> hence the reason for the Alias commands at the beginning of
>>>>> this config file.
>>>>>
>>>>> Thanks again in advance for any and all offers of help,
>>>>> thoughts, and replies...
>>>>
>>>> Your best bet is to name the context in Tomcat to be whatever
>>>> you really want the URL path to be. This will remove all kinds
>>>> of problems you are likely to see in the future because of your
>>>> decision to try to rewrite URLs.
>>>>
>>>> I never understand why people would rather spend a great deal
>>>> of time configuring around the fact that this simple command
>>>> will get everything working without any other issues:
>>>>
>>>> $ mv webapps/name-you-have webapps/name-you-want
>>>>
>>> +10 Because once you start playing with Aliases and RewriteRules,
>>> you are setting yourself up for a lot of future additional
>>> complications in terms of Redirects, Authentication, etc.. most
>>> of which you cannot even imagine right now.
>>>
>> Thanks Christopher, Andre for your comments and I will certainly
>> take them under consideration. If I were working in a simple
>> environment where all I had to do was to focus on Tomcat and Apache
>> I would certainly agree with you. Your simplistic solution of
>> renaming directories would indeed be the correct choice.
>>
>> The problem is, is that the real world is not quite so
>> accommodating. I am trying to support a team of users who are using
>> other third party applications and also using cross-sectional tools
>> that require multiple resources/directories in the Tomcat/Apache
>> web directories, that all need to be coordinated. Some of this can
>> be solved with directory renaming or links, but in some cases it
>> becomes a question of whether the dog is wagging the tail or the
>> tail is wagging the dog in terms of the amount of work involved to
>> solve a problem; such as a simple Tomcat/Apache alone related
>> answer (directory renaming) implies. So I am exploring the choices
>> I have within the Tomcat/Apache tool space in order to determine
>> what choice is best. If indeed the tools available within Tomcat
>> and Apache are so odious to use, then yes I will also have to
>> explore the option of changing other tools, software, and
>> configurations in order to accommodate Tomcat and Apache.
>
> It's not a question of whether of not the tools are odious, it's the
> fact that a highly-complicated environment is going to require
> highly-complicated configuration. I'm suggesting that you simplify
> things. You will quickly find that you will need to start re-writing
> entire pages of content to fix-up link URLs and stuff like that.
> mod_proxy will only auto-rewrite headers such as Location (for
> redirects) and Set-Cookie; it will not fix all of the links that the
> web application produces.
>
> At the point that you start re-writing entire pages of content as they
> traverse your reverse-proxy is when you know you are really fighting
> against a Better Way of doing things.
>
> Are you suggesting that your environment is so complex that it is not
> possible to change the name of a single file/directory (possibly
> amongst a cluster of servers, of course)? The alternative is miles of
> configuration that probably will always have some kind of problem with
> it because you have missed an edge case.
>
>> My understanding of Tomcat and Apache is that they are supposedly
>> robust enterprise grade tools, designed to work in complex
>> environments. So my hope is that issues like this have been already
>> addressed with elegant solutions. ;-)
>
> The elegant solution is to re-name your application to the
> context-path you want to use, rather than using a mountain of band-aids.
>
> This is not a problem unique to Tomcat and/or Apache httpd. You'll
> find this same problem with every other reverse proxy / servlet
> container combination that I know of.
>
>> FYI I am using the jsp and servlet examples here as just a simple
>> model of what I want to accomplish. I could really care less about
>> those particular web applications.
>
> Understood.
>

I can only agree with Christopher.
The tools available in Apache httpd and Apache Tomcat are plentiful, powerful, flexible, 
and allow basically any mangling that you might think of in terms of URLs and what actual 
resource they point to.
The problem is all the other bits, such as what Christopher mentions about the 
applications creating pages with embedded links to further resources. And the problem is 
also in how the browser, in receiving such pages, will interpret these links (relative or 
absolute).  There exist tools in Apache httpd and Tomcat to handle this too (think "output 
filters"), but the point is that once you start with this, you don't really know where it 
will end.
And even more so, if you do not know the applications in detail, and/or you have no 
possibility to influence how they are written.
(Think e.g. of links in pages such as : <img src="../images/logo.gif"> and what the 
browser would make of it).


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