Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Subject: Re: encodeURL, jsessionid and mod_rewrite ?
To: users@tomcat.apache.org
References: <CACqpeO-rgrsqyNsYz425Ts+_5p7ssCBkMutuKfBHxH4JSJzDuw@mail.gmail.com>
 <6e827382-25c7-0be0-a62b-40a6a9fd40e6@christopherschultz.net>
From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat=29?= <aw@ice-sa.com>
Message-ID: <59D49374.5000309@ice-sa.com>
Date: Wed, 4 Oct 2017 09:53:24 +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: <6e827382-25c7-0be0-a62b-40a6a9fd40e6@christopherschultz.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Wed, 04 Oct 2017 07:53:47 -0000

On 04.10.2017 02:44, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Laurant,
>
> On 10/3/17 5:17 PM, Laurent Perez wrote:
>> I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
>> "foo" war is deployed at /foo context path under tomcat. The /foo
>> path is not public, apache has a rewrite rule defined as : /bar/*
>> rewrites internally to /foo/*.
>>
>> I'm using jstl and its <c:url value="page.jsp"> for every url in my
>> jsps to gain the ;jsessionid from encodeURL whenever jsessionid
>> cookie is not yet set (1st requests)
>>
>> Now my question is : the <c:url> results in a
>> "/foo/page.jsp;jsessionid=..." I want the result instead as
>> /bar/pages.jsp;jsessionid=....
>>
>> Should I go straight for a HttpServletResponseWrapper replacing
>> every /foo/ with /bar/ or is there a more elegant way ? If the
>> apache rewrite rule is modified - say, to /barv2/, is it ok to use
>> mod_headers to pass the original path instead of hardcoding /bar/
>> ?
>
> You are going down a path that will produce endless problems, hacks,
> and ugly solutions to those problems. It will be much easier for you
> to simply re-name your application from "foo" to "bar" and not worry
> about any of this rewriting foolishness.
>
> - -chris

+1.
I can only agree 100% with what Chris is saying above.
The fact that you /can/ do these things at the front-end proxy level, does not mean that 
it is a good idea to do it.  There are probably cases when you can *really* not do 
otherwise, and that's why these mechanisms are there.
But doing this, brings endless other practical inconvenients, extra work, confusion, 
documentation issues, understanding issues 6 months later, support issues, etc.
So, in a nutshell : don't do it.

P.S. The annoying bit about recommendations such as the above, is that if you follow them, 
you will not even know how much work and hassle you have saved to yourself, and
1) you will not even feel thankful
and
2) we won't have the satisfaction of saying later : "well, we told you so"
;-)


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