Skip to content

11.x: regex_remap: Remove // prefix from host match string#12706

Closed
bneradt wants to merge 1 commit intoapache:11-Devfrom
bneradt:fix_regex_remap_and_scheme
Closed

11.x: regex_remap: Remove // prefix from host match string#12706
bneradt wants to merge 1 commit intoapache:11-Devfrom
bneradt:fix_regex_remap_and_scheme

Conversation

@bneradt
Copy link
Contributor

@bneradt bneradt commented Nov 25, 2025

When the host option was enabled, regex_remap prepended '//' before the host in the match string, resulting in '//host/path' instead of 'host/path'. This was confusing because users associated the '//' with the 'http://' scheme, leading to double-slash issues when writing HTTP-to-HTTPS redirect rules. The match string now uses 'host/path' format. Documentation and tests have been updated accordingly, including new examples for host and method options.

Fixes: #12691

There was a dev mailing list email about this and no one complained about the change. Applying lazy consensus, I'm marking this PR as ready for review.

@bneradt bneradt added this to the 11.0.0 milestone Nov 25, 2025
@bneradt bneradt self-assigned this Nov 25, 2025
@bneradt bneradt added Incompatible regex_remap regex_remap plugin labels Nov 25, 2025
@bneradt bneradt marked this pull request as draft November 26, 2025 20:30
When the host option was enabled, regex_remap prepended '//' before the host
in the match string, resulting in '//host/path' instead of 'host/path'. This
was confusing because users associated the '//' with the 'http://' scheme,
leading to double-slash issues when writing HTTP-to-HTTPS redirect rules.
The match string now uses 'host/path' format. Documentation and tests have
been updated accordingly, including new examples for host and method options.

Fixes: apache#12691
@bneradt bneradt force-pushed the fix_regex_remap_and_scheme branch from cd88e89 to baa76fc Compare December 1, 2025 17:06
@bryancall bryancall requested a review from zwoop December 1, 2025 22:47
@bneradt bneradt marked this pull request as ready for review December 2, 2025 23:39
@bneradt
Copy link
Contributor Author

bneradt commented Dec 3, 2025

@zwoop had the following comment to the mailing list thread:

I don’t have a strong opinion either way, but I have a vague recollection
that this came from the fact that someone used to have hostnames in the
path. E.g. something like (maybe…)

    https://cdn.example.com/origin1.example.com/some/path/
    https://cdn.example.com/origin2.example.com/some/path/

etc. And I *think* that's the reason for keeping the // with the authority,
making it easy, safe (and maybe even possible sometimes) to distinguish it
from the path. I.e. a regex like

   /\/\/cdn.*.com\/(.*\.example\.com)/

So, I’m -0 on this change, and I don’t know if it’s a use case anyone have
now. As such, I’m ok landing this, but given a choice I probably wouldn’t.

Cheers,

— Leif

This is a good point. That being the case, I'm going to close this PR and replace it with a documentation update PR making sure this behavior is well explained: #12730

@bneradt bneradt closed this Dec 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Incompatible regex_remap regex_remap plugin

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Odd regex_remap target match string when "host" option is used - contains partial scheme string

1 participant