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 ^/lundase/(.*)$ http://localhost:9090/lundase/$1 [NC,P,L]
#RewriteRule ^/binary/(.*)$ http://localhost:9090/lundase/binary/$1 [NC,P,L]
#RewriteRule ^/content/(.*)$ http://localhost:9090/lundase/content/$1 [NC,P,L]
#RewriteRule ^.*/[^./]+$ $0/ [NC,R=301,L]
RewriteRule ^(.*)$ http://localhost:9090/lundase/$1 [NC,P,L]
 
ContextPath: /lundase
Ussualy we have urls of this type for example:
/lunda-online/index.html
also /lunda-online/  works correctly 
but /lunda-online without end slash  triggered redirects by with found resource 
/lundase/lunda-online/
and proxy in turn generates a request of this type: lundase/lundase/lunda-online
And file structure to this page 
lundase (dir) → lunda-online (dir) → index.html
 
index.html example:
<%@ page session="false"
        pageEncoding="UTF-8"
        import="com.gridnine.platform.server.lundase.web.content.*"
        import="com.gridnine.platform.common.lundase.model.content.*"
%><%
MetaVO meta = SiteMetadataHelper.getStaticMeta(MainSitePage.LUNDA_ONLINE);
%><jsp:include page="/source/frametemplates/master.jsp">
    <jsp:param name="title" value="<%= meta.getTitle() %>"/>
    <jsp:param name="description" value="<%= meta.getDescription() %>"/>
    <jsp:param name="content" value="lunda-online.jsp"/>
</jsp:include>
  
>Вторник, 27 декабря 2022, 13:42 +03:00 от Mark Thomas <ma...@apache.org>:
> 
>
>On 27/12/2022 06:25, Fedor Makarov wrote:
>>
>>
>> Tomcat 9.0.65
>> Hello I have some problems with redirects by requests without trailing 
>> slashes.
>>
>> When I try to get to the page for example: "about/page" tomcat understands 
>> that it is necessary to add a slash and adds it, however, he also adds the 
>> name of the root folder to this, that is, the url "lundase/about/page/" 
>> turns out, and any requests to our server via apache are proxied with the 
>> addition of "lundase", so it turns out that we are accessing the application 
>> on request "lundase/lundase/about/page/" which results in a 404 status.
>>
>> I googled it and found two properties:
>> context.setMapperContextRootRedirectEnabled(false)
>> context.setMapperDirectoryRedirectEnabled(false)
>> And tryed to play with them, however, it's not resolve my problem please can 
>> you help me with it?
>
><snip/>
>
>The request "/about/page" (the leading '/' is important) doesn't match
>any of the provided servlet mappings:
>
>> <url-pattern>/client-error/*</url-pattern>
>> <url-pattern>/warehouses/*</url-pattern>
>> <url-pattern>/properties-for-rent/*</url-pattern>
>> <url-pattern>/about/events/*</url-pattern>
>> <url-pattern>/ping/*</url-pattern>
>> <url-pattern>/catalogue/*</url-pattern>
>> <url-pattern>/binary/*</url-pattern>
>> <url-pattern>/content/*</url-pattern>
>> <url-pattern>/lundaprogrammet/*</url-pattern>
>> <url-pattern>/source/assets/css/aggregate.css</url-pattern>
>
>so the request will be mapped to the default servlet.
>
>The redirect will be generated (depending on the value of
>mapperDirectoryRedirectEnabled) either by the Mapper or the default
>servlet. All that affects is when the redirect is generated. The
>redirect will be the same in either case.
>
>We need to know:
>- The httpd proxy configuration
>- the context path (assumed to be "/lundase" )
>- the full URL path (you can skip the protocol, host and port) of the
>   request that triggers the problem
>
>Mark
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:  users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail:  users-h...@tomcat.apache.org
 
 
---
Fedor Makarov
 

Reply via email to