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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
