bneradt commented on issue #12691: URL: https://github.com/apache/trafficserver/issues/12691#issuecomment-3577989928
I did notice that the docs do actually hint at this behavior: https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/regex_remap.en.html > Finally, to match on the host as well, use the option ‘host’, e.g. > > ... @pparam=maps.reg @pparam=host > With this enabled, the string that you will need to match will look like > > //host/path?query=bar Note that initial `//` for host. Having said that, this is unintuitive. Who would expect that for a URL like `https://example.com/path`, host would be `//example.com`? Most people expect the host to not contain `//`, see RFC 3986: https://www.rfc-editor.org/rfc/rfc3986#section-3 ``` foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment ``` Note that the authority (host in this context) doesn't contain the `//`. Thus this is a confusing usability issue, causing users to need to spend time figuring out why `https://$1` doesn't work because they need to `https:$1` instead, as @djcarlin needed to do above. My plan is to fix this behavior by simply removing `//` from the host value. We cannot, however, just change the behavior of `host` mid 10.x as that would be a breaking change. I'll work on an 11.x PR via our 11-Dev branch. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
