On 12/01/2023 05:08, Fedor Makarov wrote:
lundase and vvsguiden webapps used on different domains
My recommendation would be to configure Tomcat for virtual hosting as
well. [1]
For example, configure the following hosts in the local hosts file:
lundase-local
vvsguiden-local
Then the httpd redirects become:
RewriteRule ^(.*)$ http://lundase-local:9090/$1 [P]
and
RewriteRule ^(.*)$ http://vvsguiden-local:9090/$1 [P]
respectively.
And in Tomcat you have:
<Engine name="Catalina" defaultHost="lundase-local">
<Host name="lundase-local" appBase="webapps-lundase"/>
<Host name="vvsguiden-local" appBase="webapps-vvsguiden"/>
</Engine>
With appropriate ROOT.war files (and any additional web applications)
deployed in the appropriate webapps-... directory.
If you don't want to go the virtual hosting route, you could have
multiple Tomcat instances on different ports or multiple <Service>
elements in one instance e.g.
<Server .../>
...
<Service name="lundase">
<Connector port="9090" .../>
<Engine name="lundase" defaultHost="localhost">
...
</Engine>
</Service>
<Service name="vvsguiden">
<Connector port="9091" .../>
<Engine name="vvsguiden" defaultHost="localhost">
...
</Engine>
</Service>
</Server>
Although I do think the virtual hosting approach is the simplest - and
it maps neatly to the httpd configuration.
Mark
[1] https://tomcat.apache.org/tomcat-9.0-doc/virtual-hosting-howto.html
<VirtualHost *:80>
<------>ServerName new.vvsguiden-dev.gridnine.com
<------>ServerAlias localhost
<------>ServerAdmin webmaster@localhost
<------>DocumentRoot /var/www/html
<------>RewriteEngine on
<------>ProxyPreserveHost on
<Directory "/site-binary-data/fb">
Order allow,deny
Allow from all
Require all granted
</Directory>
# static content
RewriteRule ^/fb/(.*)$ /site-binary-data/fb/$1 [L]
<------>RewriteRule ^/vvsguidenapi/(.*)$ http://localhost:9090/vvsguidenapi/$1 [NC,P,L]
<------>RewriteRule ^(.*)$
http://localhost:9090/vvsguiden/$1 [NC,P,L]
<------>
<VirtualHost *:443>
<------>ServerName m.new.lundagrossisten-dev.gridnine.com
<------>ServerAdmin webmaster@localhost
<------><LocationMatch "^/lundaprogrammet/.*">
Вторник, 10 января 2023, 11:41 +03:00 от Mark Thomas <ma...@apache.org>:
On 10/01/2023 04:37, Fedor Makarov wrote:
Also I tried to write a filter to manually redirect, but tomcat intercepts the
request before it gets into the filter. Can I disable this behavior for tomcat
and do it manually?
That isn't the way to solve this problem. The problem is in the reverse
proxy configuration and that is where you need to fix it.
You previously provided the following set of rules:
RewriteCond %{REQUEST_URI} ^(/api/|/mapi/|/binary/|/rpc/invoker/)
RewriteRule ^/rpc/invoker/(.*)$ http://localhost:9090/rpc/invoker/$1
[NC,P,L]
RewriteRule ^/api/(.*)$ http://localhost:9090/api/$1 [NC,P,L]
RewriteRule ^/mapi/(.*)$ http://localhost:9090/mapi/$1 [NC,P,L]
RewriteRule ^(.*)$ http://localhost:9090/lundase/$1 [NC,P,L]
I'll note that the RewriteCond appears to be unnecessary.
I'll further note that the NC flag appears to be unnecessary. As is the
L flag (P implies L).
We can help you fix these rules but when we tried you mentioned
"vvsguiden" but that does not appear in the rewrite rules.
mod_rewrite isn't necessarily the best way to configure a reverse proxy
but if that is what you are familiar with, we can work with it. What we
do need, regardless of how the reverse proxy is configured, is a
complete list of the mappings you want to implement.
To re-iterate Chris's earlier point, trying to change the context path
for an application in a reverse proxy is asking for trouble. It is far
better to reconfigure the contexts in Tomcat so the reverse proxy
doesn't need to change the URI path.
Based on the paths above, you need to redeploy lundase.war as ROOT.war
and then the rewrite rules become:
RewriteRule ^(.*)$ http://localhost:9090/$1 [P]
We need more details for "vvsguiden" to figure out why the above won't work.
Mark
Понедельник, 9 января 2023, 11:43 +03:00 от Fedor Makarov < ary...@mail.ru.invalid
>:
We have to webapps lundase and vvsguiden therefore, the options you have
suggested do not look applicable on debug I saw that RequestURI in request
looks like lundase/lundase/...
Вторник, 27 декабря 2022, 22:06 +03:00 от Christopher Schultz <
ch...@christopherschultz.net >:
Fedor,
On 12/27/22 05:55, Fedor Makarov wrote:
proxy for local environment we use the js conf:
proxy: {
'/api/': {
target: 'http://localhost:8080/',
changeOrigin: false,
},
'/': {
target: 'http://localhost:8080/lundase',
changeOrigin: false
}
},
for normal lunch we use apache2.conf:
RewriteCond %{REQUEST_URI} ^(/api/|/mapi/|/binary/|/rpc/invoker/)
RewriteRule ^/rpc/invoker/(.*)$ http://localhost:9090/rpc/invoker/$1 [NC,P,L]
RewriteRule ^/api/(.*)$ http://localhost:9090/api/$1 [NC,P,L]
RewriteRule ^/mapi/(.*)$ http://localhost:9090/mapi/$1 [NC,P,L]
RewriteRule ^(.*)$ http://localhost:9090/lundase/$1 [NC,P,L]
What you are doing is trying to remove the context-path of the
application through URL re-writing which will probably cause endless
problems during the life of your application.
I have two possible suggestions for you:
1. Re-name your application from lundase to ROOT (to deploy it to /
instead of /lundase).
or
2. Don't try to remove the /lundase URL prefix as part of your URL
rewriting.
If you don't choose one or the other of these options, you will find
that you have many years of debugging and trying to fix up every little
weird thing that happens with cookies, redirects, and in-page links.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---
Fedor Makarov
---
Fedor Makarov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---
Fedor Makarov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
