Apache 2.4 rewriting directory URLs without trailing slash to https://default_site/dir/ instead of preserving domain

Question

This is a relatively recent behavioral change and appears to be related only to requests which include a "Upgrade-Insecure-Requests: 1" request header.

Apache has started rewriting such requests for sites which are HTTP-only to an HTTPS URL using the default site name instead of just adding the / at the end of the requested URL.

Example: URL submitted in browser: http://www.example.com/blah
Intended redirect: 301 to http://www.example.com/blah/
Instead redirects: 301 to https://default.site.configured/blah/

This happens whether it's a named virtual on the same address as the default server or a virtual using a separate address with separate Listen directives.

I understand all the arguments in favor of the idea that everything should always be encrypted and I don't want to get into a debate about that. This site doesn't consider the tradeoffs desirable at this time.

The default site does have SSL and is configured to redirect HTTP->HTTPS, but the www.foo.com site is not configured that way and does not wish to implement SSL at this time.

Is there any way to get Apache 2.4 to disregard that "Upgrade" header and simply rewrite the URL as desired rather than altering the domain name?

Answer 1

After banging on this some more, I finally found the source of my woes.

This happens when you have IP based virtual hosts and did not configure a name for them using the "ServerName" directive.

tl;dr: If you are having this problem, try adding a "ServerName www.example.com" directive within the VirtualHost definition for the site and that should resolve it.

Details: It does not happen until you encounter a URL that requires a rewrite other than adding a trailing /. (ie if you get a request that doesn't contain the "Upgrade-Insecure-Requests: 1" header, it only gets the trailing / added, but if you get one with that header, it also tries to rewrite the protocol to https which triggers the full URL rewrite).

In my case, the default host name had an SSL configuration, so it didn't fall back to HTTP after the rewrite or reject the rewrite as invalid.

YMMV, I did not continue to do an exhaustive test of all permutations once I found the solution.