Re: [External] Re: RemoteAddrFilter (org.apache.catalina.filters)

[Christopher Schultz]

Tim,

On 3/21/22 16:47, Scott,Tim wrote:

Hi Chris and Mark,

As Mark spotted, I'm editing the conf/web.xml file.

If I move this to the application's web.xml, is there any way it can
be overridden by the Tomcat configuration? Ideally, I'd like it to be
somehow configurable by the person deploying it.
You mean, you want the deployer/administrator to be able to configure 
this and NOT HAVE the application packager override that configuration, 
right?


I think maybe you want to se the Remote Address Valve[1] and not Filter.

Valves can be configured in the application's META-INF/context.xml file, 
and those files can be specified by the deployer and will override 
whatever comes packaged in the web application.


Stick a file in CATALINA_BASE/conf/[service]/[engine]/[appname].xml and 
configure the Valve there, and the application won't overwrite that file 
unless you un-deploy the application and re-deploy it.


Another option would be to configure the Valve at the  or  
level in your conf/server.xml file. that way it's all in one place. But 
it applies to *all* applications when you do it this way; you don't 
specify a  for a Valve, for example.



Alternatively, can it be configured programmatically?


I don't see a reason to do this programmatically, unless you are using 
Embedded Tomcat already.



I could then read a setting from the database.


Well, if that's a fun thing or you to do, then sure, programmatically 
would allow you to do this kind of thing ;))



(Apologies for not describing all the requirements at the outset - users, eh?)


No problem.

-chris

[1] 
https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Remote_Address_Valve




From: Christopher Schultz 
Sent: Monday, March 21, 2022 8:14 pm
To: users@tomcat.apache.org
Subject: [External] Re: RemoteAddrFilter (org.apache.catalina.filters)

Tim,

On 3/21/22 13:51, Scott,Tim wrote:

Hi all,

I’ve been trying to get this to work for a bit without any luck.

What I’ve arrived at, in my main Tomcat web.xml, is:

http://xmlns.jcp.org/xml/ns/javaee
>

   
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
>

   
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee

http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd
>"

version="4.0">

 

   Remote Address Filter


org.apache.catalina.filters.RemoteAddrFilter

   

 allow

 127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1

   

 

 

   Remote Address Filter

   /sru/*

 

This is more-or-less a copy/paste from the documentation at
https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#Remote_Address_Filter
>,
but the url-pattern is presenting me some problems.

There are (for various business reasons) planned to be two applications
on this Tomcat – one at “/sru/…” and one not.

The one at “/sru” needs to have a filter applied to stop it being
accessed from non-whitelisted sources. The other application is public.

Or, I need to do some development work to integrate with our corporate
authentication mechanism – for requests that have already been
authenticated and are arriving from another, internal, server. To me,
that seems like a waste of time.

If I adjust the url-pattern to:

   /*

… then all access from other clients for both applications get an
http/403 response. No surprise, there.

If I make the pattern:

   /sru/*

(or some variations thereof – “sru”, “/sru”, “/sru/”,
“/sru*”, …)

… then both applications are equally accessible from other clients.

Is what I’m trying to do possible?

I’m using Tomcat 9.0.54.

If it should work – can anyone spot what I’ve missed?

Thanks,

Tim


What is the context path of your web application? The filter should
ignore the context-path and only look at URLs relative to that context-path.

So if you your context-path is /sru then you really just want to look at
/* and not /sru*

The other question is "which web.xml are you editing"? If you are
editing the one in CATALINA_BASE/conf/web.xml then that's the wrong one
as it applies to all web applications... but again the URLs will all be
relative to their individual context-paths.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

Re: [External] Re: RemoteAddrFilter (org.apache.catalina.filters)

[Mark Thomas]

On 21/03/2022 20:47, Scott,Tim wrote:

Hi Chris and Mark,

As Mark spotted, I'm editing the conf/web.xml file.

If I move this to the application's web.xml, is there any way it can be 
overridden by the Tomcat configuration?
Ideally, I'd like it to be somehow configurable by the person deploying it.


You can do that but you need to switch from using a Filter to using a 
Valve. Valves can configured in context.xml files. Assuming the web app 
doesn't already have a context.xml file, that would probably be the 
easiest way to do this.


Mark



Alternatively, can it be configured programmatically?
I could then read a setting from the database.

(Apologies for not describing all the requirements at the outset - users, eh?)

Thanks,
Tim

--

Tim Scott

OCLC · Senior OLIB Software Engineer
City Gate · 8 St. Mary's Gate · Sheffield S1 4LW · United Kingdom

cc: IT file



From: Christopher Schultz 
Sent: Monday, March 21, 2022 8:14 pm
To: users@tomcat.apache.org
Subject: [External] Re: RemoteAddrFilter (org.apache.catalina.filters)

Tim,

On 3/21/22 13:51, Scott,Tim wrote:

Hi all,

I’ve been trying to get this to work for a bit without any luck.

What I’ve arrived at, in my main Tomcat web.xml, is:

http://xmlns.jcp.org/xml/ns/javaee
>

   
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
>

   
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee

http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd
>"

version="4.0">

 

   Remote Address Filter


org.apache.catalina.filters.RemoteAddrFilter

   

 allow

 127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1

   

 

 

   Remote Address Filter

   /sru/*

 

This is more-or-less a copy/paste from the documentation at
https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#Remote_Address_Filter
>,
but the url-pattern is presenting me some problems.

There are (for various business reasons) planned to be two applications
on this Tomcat – one at “/sru/…” and one not.

The one at “/sru” needs to have a filter applied to stop it being
accessed from non-whitelisted sources. The other application is public.

Or, I need to do some development work to integrate with our corporate
authentication mechanism – for requests that have already been
authenticated and are arriving from another, internal, server. To me,
that seems like a waste of time.

If I adjust the url-pattern to:

   /*

… then all access from other clients for both applications get an
http/403 response. No surprise, there.

If I make the pattern:

   /sru/*

(or some variations thereof – “sru”, “/sru”, “/sru/”,
“/sru*”, …)

… then both applications are equally accessible from other clients.

Is what I’m trying to do possible?

I’m using Tomcat 9.0.54.

If it should work – can anyone spot what I’ve missed?

Thanks,

Tim


What is the context path of your web application? The filter should
ignore the context-path and only look at URLs relative to that context-path.

So if you your context-path is /sru then you really just want to look at
/* and not /sru*

The other question is "which web.xml are you editing"? If you are
editing the one in CATALINA_BASE/conf/web.xml then that's the wrong one
as it applies to all web applications... but again the URLs will all be
relative to their individual context-paths.

-chris

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



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

Re: [External] Re: RemoteAddrFilter (org.apache.catalina.filters)

[Scott,Tim]

Hi Chris and Mark,

As Mark spotted, I'm editing the conf/web.xml file.

If I move this to the application's web.xml, is there any way it can be 
overridden by the Tomcat configuration?
Ideally, I'd like it to be somehow configurable by the person deploying it.

Alternatively, can it be configured programmatically?
I could then read a setting from the database.

(Apologies for not describing all the requirements at the outset - users, eh?)

Thanks,
Tim

--

Tim Scott

OCLC · Senior OLIB Software Engineer
City Gate · 8 St. Mary's Gate · Sheffield S1 4LW · United Kingdom

cc: IT file



From: Christopher Schultz 
Sent: Monday, March 21, 2022 8:14 pm
To: users@tomcat.apache.org
Subject: [External] Re: RemoteAddrFilter (org.apache.catalina.filters)

Tim,

On 3/21/22 13:51, Scott,Tim wrote:
> Hi all,
>
> I’ve been trying to get this to work for a bit without any luck.
>
> What I’ve arrived at, in my main Tomcat web.xml, is:
>
>  xmlns=http://xmlns.jcp.org/xml/ns/javaee
> >
>
>   
> xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
> >
>
>   
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
>
> http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd
> >"
>
> version="4.0">
>
> 
>
>   Remote Address Filter
>
>
> org.apache.catalina.filters.RemoteAddrFilter
>
>   
>
> allow
>
> 127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1
>
>   
>
> 
>
> 
>
>   Remote Address Filter
>
>   /sru/*
>
> 
>
> This is more-or-less a copy/paste from the documentation at
> https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#Remote_Address_Filter
> >,
> but the url-pattern is presenting me some problems.
>
> There are (for various business reasons) planned to be two applications
> on this Tomcat – one at “/sru/…” and one not.
>
> The one at “/sru” needs to have a filter applied to stop it being
> accessed from non-whitelisted sources. The other application is public.
>
> Or, I need to do some development work to integrate with our corporate
> authentication mechanism – for requests that have already been
> authenticated and are arriving from another, internal, server. To me,
> that seems like a waste of time.
>
> If I adjust the url-pattern to:
>
>   /*
>
> … then all access from other clients for both applications get an
> http/403 response. No surprise, there.
>
> If I make the pattern:
>
>   /sru/*
>
>(or some variations thereof – “sru”, “/sru”, “/sru/”,
> “/sru*”, …)
>
> … then both applications are equally accessible from other clients.
>
> Is what I’m trying to do possible?
>
>I’m using Tomcat 9.0.54.
>
> If it should work – can anyone spot what I’ve missed?
>
> Thanks,
>
> Tim

What is the context path of your web application? The filter should
ignore the context-path and only look at URLs relative to that context-path.

So if you your context-path is /sru then you really just want to look at
/* and not /sru*

The other question is "which web.xml are you editing"? If you are
editing the one in CATALINA_BASE/conf/web.xml then that's the wrong one
as it applies to all web applications... but again the URLs will all be
relative to their individual context-paths.

-chris

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

Re: RemoteAddrFilter (org.apache.catalina.filters)

[Christopher Schultz]

Tim,

On 3/21/22 13:51, Scott,Tim wrote:

Hi all,

I’ve been trying to get this to work for a bit without any luck.

What I’ve arrived at, in my main Tomcat web.xml, is:

http://xmlns.jcp.org/xml/ns/javaee 



   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance 



   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee

http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd 
"


version="4.0">

     

   Remote Address Filter

   
org.apache.catalina.filters.RemoteAddrFilter


   

     allow

     127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1

   

     

     

   Remote Address Filter

   /sru/*

     

This is more-or-less a copy/paste from the documentation at 
https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#Remote_Address_Filter 
, 
but the url-pattern is presenting me some problems.


There are (for various business reasons) planned to be two applications 
on this Tomcat – one at “/sru/…” and one not.


The one at “/sru” needs to have a filter applied to stop it being 
accessed from non-whitelisted sources. The other application is public.


Or, I need to do some development work to integrate with our corporate 
authentication mechanism – for requests that have already been 
authenticated and are arriving from another, internal, server. To me, 
that seems like a waste of time.


If I adjust the url-pattern to:

   /*

… then all access from other clients for both applications get an 
http/403 response. No surprise, there.


If I make the pattern:

   /sru/*

    (or some variations thereof – “sru”, “/sru”, “/sru/”, 
“/sru*”, …)


… then both applications are equally accessible from other clients.

Is what I’m trying to do possible?

    I’m using Tomcat 9.0.54.

If it should work – can anyone spot what I’ve missed?

Thanks,

Tim


What is the context path of your web application? The filter should 
ignore the context-path and only look at URLs relative to that context-path.


So if you your context-path is /sru then you really just want to look at 
/* and not /sru*


The other question is "which web.xml are you editing"? If you are 
editing the one in CATALINA_BASE/conf/web.xml then that's the wrong one 
as it applies to all web applications... but again the URLs will all be 
relative to their individual context-paths.


-chris

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

Re: RemoteAddrFilter (org.apache.catalina.filters)

[Mark Thomas]

On 21/03/2022 17:51, Scott,Tim wrote:

Hi all,

I’ve been trying to get this to work for a bit without any luck.

What I’ve arrived at, in my main Tomcat web.xml, is:


Everything in conf/web.xml effectively gets copied to each individual 
web application's web.xml.



If it should work – can anyone spot what I’ve missed?


Move the Filter definition and URL pattern from conf/web.xml and add it 
to the web.xml for the application deployed at "/sru" and change the URL 
pattern to "/*".


Mark

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

RemoteAddrFilter (org.apache.catalina.filters)

[Scott,Tim]

Hi all,

I’ve been trying to get this to work for a bit without any luck.

What I’ve arrived at, in my main Tomcat web.xml, is:

http://xmlns.jcp.org/xml/ns/javaee
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
  http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd;
  version="4.0">


  Remote Address Filter
  org.apache.catalina.filters.RemoteAddrFilter
  
allow
127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1
  


  Remote Address Filter
  /sru/*


This is more-or-less a copy/paste from the documentation at 
https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#Remote_Address_Filter,
 but the url-pattern is presenting me some problems.

There are (for various business reasons) planned to be two applications on this 
Tomcat – one at “/sru/…” and one not.

The one at “/sru” needs to have a filter applied to stop it being accessed from 
non-whitelisted sources. The other application is public.

Or, I need to do some development work to integrate with our corporate 
authentication mechanism – for requests that have already been authenticated 
and are arriving from another, internal, server. To me, that seems like a waste 
of time.

If I adjust the url-pattern to:
  /*

… then all access from other clients for both applications get an http/403 
response. No surprise, there.

If I make the pattern:
  /sru/*
   (or some variations thereof – “sru”, “/sru”, “/sru/”, “/sru*”, …)

… then both applications are equally accessible from other clients.

Is what I’m trying to do possible?
   I’m using Tomcat 9.0.54.

If it should work – can anyone spot what I’ve missed?

Thanks,
Tim

--
Tim Scott
OCLC · Senior Software Engineer / Technical Product Manager
CityGate, 8 St. Mary’s Gate, Sheffield S1 4LW, UK

cc: IT file

OCLC COVID-19 resources: 
oc.lc/covid19-service-info
[COVID-19: We’re in this 
together]

Re: Question about Tomcat 8.5.77 and CVE-2022-0778

[Mark Thomas]

On 21/03/2022 16:26, Matthew Mellon wrote:
Tomcat 8.5.77 was published on March 17. The Windows distribution 
contains tcnative-1.dll, version 1.2.31.


Tcnative-1.dll appears to be statically linked to OpenSSL, and was built 
in 2021, prior to the fix for CVE-2022-0778 being published by OpenSSL.


The tcnative source tree was updated to “recommend” a new version of 
OpenSSL six days ago, but the DLL in the 8.5.77 release doesn’t appear 
to have been built with this change.


I believe this means that if an APR connector is enabled, that the 
Windows distribution of Tomcat 8.5.77 is exposed to a pretty severe DOS 
attack vector. I emailed secur...@tomcat.apache.org 
 about this, believing that that was 
the responsible way to bring this to light, but received a pretty nasty 
email in response that told me that this mailing list was the correct forum.


CVE-2022-0778 is public. You posted a question to the Apache Tomcat 
security team that did not concern an undisclosed security vulnerability 
in Apache Tomcat. This happens sufficiently often that we have a canned 
response for when this happens. For the record this is the content of 
that canned response:



To whom it may concern,

You recently contacted the Apache Tomcat security team. As explained
in [1], the e-mail address you used should only be used for
reporting undisclosed security vulnerabilities in Apache Tomcat and
managing the process of fixing such vulnerabilities. Your e-mail does
not meet that criteria.

You may wish read some information on how the ASF works [2] before
proceeding with your enquiry via the appropriate channel which will
almost certainly be the Apache Tomcat users mailing list. [3]

The Apache Tomcat security team

[1] http://tomcat.apache.org/security.html
[2] http://apache.org/foundation/how-it-works.html
[3] https://tomcat.apache.org/lists.html#tomcat-users


Would it be possible to get a canonical version of Tomcat (e.g. 8.5.78) 
built that contains the remediation for CVE-2022-0778?


There is a Tomcat Native 1.2.32 release in progress at the moment that 
includes convenience Windows binaries built with OpenSSL 1.1.1n.


That release vote looks like it is going to pass so that release should 
be available on the download pages sometime tomorrow.


Tomcat releases are usually monthly with the process starting at the 
beginning of the month. I'd therefore expect to see an 8.5.78 release 
roughly around the second week of April that included the Tomcat Native 
1.2.32 release.



Is there anything I can do to help?


Test the Tomcat Native 1.2.32 release. Details on the dev@ list.

The changes since 1.2.31 are minor and don't include any code changes so 
the likelihood of a regression is low. However, the more people that 
test a release and VOTE on it the better.


Test the 8.5.78 release when it happens. Watch the dev@ list for details.

Some other options:

Disable the APR/Native library so Tomcat uses NIO+JSSE instead.

Update to Tomcat Native 1.2.32 once released (single DLL for Windows 
that is a drop-in replacement).


Build 1.2.31 from source using OpenSSL 1.1.1n. The build process we use 
is documented at [1]. The hoop jumping is mainly to ensure that the 
resulting binaries will run on all currently supported Windows versions 
without requiring that additional run times etc are installed. Given 
that 1.2.32 is so close to release, it may not be worth the time 
required to follow this option.


Mark


[1] 
https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+Tomcat+Native+Connector+binaries+for+Windows




*Matthew Mellon **CISSP**
*/Chief Information Security Officer/

828.265.2907 ext 5058  | www.ecrs.com 



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

Question about Tomcat 8.5.77 and CVE-2022-0778

[Matthew Mellon]

Tomcat 8.5.77 was published on March 17. The Windows distribution contains 
tcnative-1.dll, version 1.2.31.

Tcnative-1.dll appears to be statically linked to OpenSSL, and was built in 
2021, prior to the fix for CVE-2022-0778 being published by OpenSSL.

The tcnative source tree was updated to "recommend" a new version of OpenSSL 
six days ago, but the DLL in the 8.5.77 release doesn't appear to have been 
built with this change.

I believe this means that if an APR connector is enabled, that the Windows 
distribution of Tomcat 8.5.77 is exposed to a pretty severe DOS attack vector. 
I emailed secur...@tomcat.apache.org about 
this, believing that that was the responsible way to bring this to light, but 
received a pretty nasty email in response that told me that this mailing list 
was the correct forum.

Would it be possible to get a canonical version of Tomcat (e.g. 8.5.78) built 
that contains the remediation for CVE-2022-0778? Is there anything I can do to 
help?

Matthew Mellon CISSP
Chief Information Security Officer
828.265.2907 ext 5058  |   www.ecrs.com

[cid:image001.png@01D83D1E.16997AA0]

Re: Fwd: tomcat 9.50 - rewrite rule question

[Felix Schumacher]

Am 21.03.22 um 06:39 schrieb rupali singh:

Hi Felix,

location of context.xml file is

  cat context.xml| grep RewriteValve
 
  pwd
/opt/tomcat/apache-tomcat-9.0.54/instance/conf
That context.xml is thought to be a default template for all installed 
webapps. It will work, but remember, that every installed webapp will 
get its own copy of a rewrite valve.




more
/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/apex/f$ /apex/myapp [R,L]


What happens, when you call the apex URL with curl? Something like

> curl -D- 'localhost:8080/apex/f?p=10001'

It should display (assuming your tomcat listens on port 8080) something 
like:


HTTP/1.1 302
Location: /apex/myapp?p=10001
Content-Length: 0
Date: Mon, 21 Mar 2022 ...

Felix



its still not working


On Mon, 21 Mar 2022 at 00:57, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:


Am 20.03.22 um 19:45 schrieb Thomas Hoffmann (Speed4Trade GmbH):

Hello,

url rewrite doesn't match against url parameters as far as I know.
RewriteRule ^/apex/f$  /apex/myapp [R,L]

You can match the query string by adding a RewriteCond, for example

RewriteCond %{QUERY_STRING} p=1001
RewriteRule ^/apex/f$ /apex/myapp [R,L]

(The lines have to be in that order and no other line in between)

Felix

Just a guess, maybe you can  give it a try.

Another option would be to use the source code of tomcat and set a breakpoint 
within the filter class
(just with a little dummy app deployed).

Greetings, Thomas


-Ursprüngliche Nachricht-
Von: rupali singh  
Gesendet: Sonntag, 20. März 2022 19:23
An: Tomcat Users List  
Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question

Hi,

i have referred Around 
here:https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
but still can't figure out how to write rules for my requirements..
can you please help

On Sat, 19 Mar 2022 at 21:57, Thomas Hoffmann (Speed4Trade 
GmbH)  
  wrote:


Hallo,

just scroll down the documentation.
Around here:https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
If something is not clear there, just drop a line



-Ursprüngliche Nachricht-
Von: rupali singh  
Gesendet: Samstag, 19. März 2022 18:28
An: Tomcat Users List  
Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question

Hi,

Thanks a lot for your quick response.then what options we have in
tomcat apache for rewrite rules.

Apologies im new to apache tomcat.


On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian  

wrote:


On 3/19/2022 1:03 AM, rupali singh wrote:

Hi Team,

We are using tomcat 9.54 version.
Need help in rewriting rule.

background   : We have an Oracle apex server ( version 21.1)  and

tomcat

is

installed on the same server. We have F5 url which redirects to
apex installed on tomcat  
eghttps://xyz.ae/apex/f?p=1001  
so xyz.ae is published on our F5

which

redirects internally to tomcat server on port 8080.

we want to redirecthttps://xyz.ae/apex/f?p=1001  
to
   https://xyz.ae/apex/myapp    
as it's

difficult

for business users to remember f?p=1001  


i have prepared context.xml and rewrite.config rule but
redirection not working and there is no error in catalina.log

in access log we are getting 404.

i have tried steps mentioned in


https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with
-

ord

s-and-oracle-apex

rewrite.config content

RewriteCond %{REQUEST_URI} ^/myapp$ RewriteRule 
^/myapp$https://xyz.ae/apex/myapp  [R,L]


please advise how to resolve the issue

Those look like Apache HTTPD rewrite rules. How are they supported
in Apache Tomcat?

-Terence Bandoian


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

  --
Thanks and Regards,
Rupali

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




OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature