Remove restriction preventing expressions in Redirects outside of <Location>

[robertmathews]

Currently, it's not possible to use expression syntax like this in (say) .htaccess files:

<If "%{HTTPS} != 'on'">
Redirect 301 https://%{HTTP_HOST}%{REQUEST_URI}
</If>

You have to instead use a much uglier RewriteCond/RewriteRule.

The reason it doesn't work is not because the code doesn't exist, but because mod_alias.c restricts expressions in redirects to <Location> context only for now.

It's not clear why that restriction was/is needed. I asked if anyone knew the reason for it on the httpd dev mailing list in 2022, but nobody replied: https://lists.apache.org/thread/m72z147c3rffpk7goy7n0z66l7jw16lc

My company has been running this patch on many production servers for three years with no trouble. It allows the above example to work as expected from a .htaccess file, which seems generally useful and in accordance with the "ongoing effort to only use a single variant, called ap_expr, for all configuration directives".

[robertmathews]

I'm wondering if anyone knows of a security-related reason why this should not be implemented?

@ylavic, you added the <Location> context only for now code in 2015 in commit 3c694b3; do you remember why the restriction was thought necessary?

If it's not secure, I'd like to stop using the patch myself and remove this pull request.

[ylavic]

Digging in the archives[1] (my memory fails at 10y ago) it seems that allowing expressions outside <Location> could break configurations like:

RedirectMatch 404 ".*\.sh$"

where the regular expression is a match rather than the redirected URL.

Redirect{,Match} is trying to do too many things (IMHO) and add_redirect_internal() is hard to follow, regressions is the concern here.

[1] https://lists.apache.org/thread/omk0bgf3h649tz62qblw1112kbl7p10n