Hello all,
Running version 25.10.2_4 business. I need to redirect a local path to a particular remote destination; quite a usual task for which Apache RedirectMatch can be used.
According to https://docs.opnsense.org/vendor/deciso/opnwaf.html#redirect-match, I've set up the location this way (FQDNs have been redacted):
Local path: ^/mailman/(.*)$
Remote destinations: https://<LIST-SERVER>/mailman/$1
Basically it should catch requests for https://<MAIN-SERVER>/mailman/<ANYTHING> and redirect them to https://<LIST-SERVER>/mailman/<ANYTHING>. However, it does not work, the group captured in $1 is not passed to the destination, all requests end up at https://<LIST-SERVER>/mailman/.
The corresponding piece of configuration in /usr/local/etc/apache24/Includes/gateway_vhosts.conf looks like this.
<LocationMatch "^/mailman/(.*)$">
RedirectMatch 308 "https://<LIST-SERVER>/mailman/$1"
</LocationMatch>
It doesn't seem to be correct though. <LocationMatch> does match ^/mailman/(.*)$, but RedirectMatch does NOT reuse that match, so $1 inside RedirectMatch is undefined. In Apache, <LocationMatch> captures are not passed into directives inside the block so RedirectMatch needs its own regex to define $1. Working configuration would look like this:
<VirtualHost *:443>
...
RedirectMatch 308 ^/mailman/(.*)$ https://<LIST-SERVER>/mailman/$1
Redirect 301 / https://<MAIN-SERVER>/
...
</VirtualHost>
I've actually updated gateway_vhosts.conf by hand and it works well. Until someone makes an update via GUI. :-)
Greetings,
Ivo
Hello,
could you test if this fixes it too:
<LocationMatch "^/mailman/(.*)$">
RedirectMatch 308 ^/mailman/(.*)$ https://<LIST-SERVER>/mailman/$1
</LocationMatch>
I know it looks redundant but I want to change as little about the template generation as possible to fix this.
Only if the above is totally invalid I would consider dropping location match entirely for redirect match.
Hello,
I see your point. The configuration you suggest unfortunately doesn't seem to work.
I also tried other combinations of <Location> or <LocationMatch> and Redirect or RedirectMatch, the only working one is when Redirect is nested in <Location>, as mentioned in Apache docs: https://httpd.apache.org/docs/current/mod/mod_alias.html#redirect. It does not solve the problem though.
<Location "/one">
Redirect 301 "http://newserver.com/one"
</Location>RedirectMatch apparently cannot be enclosed in <Location>, at least the documentation doesn't mention such a case: https://httpd.apache.org/docs/current/mod/mod_alias.html#redirectmatch. If I am getting it right, RedirectMatch is interpreted before LocationMatch but due to the fact that it's enclosed inside LocationMatch, the whole block never gets triggered.
However, thanks to the Apache docs and ChatGPT, I've found a workaround which can even be used with the current GUI and Redirect Match type. :-) It makes use of environment variables.
The GUI fields look like this:
Local path: /mailman/(?<CUSTOMPATH>.*)
Remote destinations: https://<LIST-SERVER>/mailman/%{env:MATCH_CUSTOMPATH}
It translates into following configuration block in gateway_vhosts.conf:
<LocationMatch "/mailman/(?<CUSTOMPATH>.*)">
RedirectMatch 308 "https://<LIST-SERVER>/mailman/%{env:MATCH_CUSTOMPATH}"
</LocationMatch>It is a bit cumbersome, but works well. :-)
As a longer-term solution, perhaps implementing some basic GUI interface for mod_rewrite in addition to mod_alias would be fruitful?
Ivo
This looks like a pretty smart solution to the immediate issue.
I have to think about how we approach this in the GUI, skipping the LocationMatch generation can be the most viable solution.
It should be quite a small diff as well.
About a GUI for rewrites, I am not completely sure about it. Raw config imports (import directives in the shell) might be the way to go at a certain point of complexity.