Page MenuHomePhabricator

Location: redirects on https sites always point to http sites
Closed, ResolvedPublic


Author: sumanah

On, if I'm on the unsecure site

and then click on the banner link to , I get directed to

I'm on Firefox 3.6.18. Installed extensions:

Ubuntu Firefox Modifications






Universal Print


Version: unspecified
Severity: normal
OS: Linux



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:35 PM
bzimport added a project: HTTPS.
bzimport set Reference to bz29981.

I assume the link you're clicking is the link... I can confirm the behavior you're seeing in Firefox 5/Linux. :(

Hitting the "/" generic root page will end up sending a redirect to the canonical location of the main page; sounds like either MediaWiki's incorrectly serving out the HTTP redirect, or it's getting incorrectly cached.

Looks like I can repro with another redirection, using a non-canonical encoding of the title:

also gets redirected to:

HTTP response headers as seen in Firebug on a redir:

Server nginx/0.7.65
Date Wed, 20 Jul 2011 17:20:12 GMT
Content-Type text/html; charset=utf-8
Connection keep-alive
Cache-Control s-maxage=1200, must-revalidate, max-age=0
Vary Accept-Encoding,Cookie
X-Vary-Options Accept-Encoding;list-contains=gzip,Cookie;string-contains=officewikiToken;string-contains=officewikiLoggedOut;string-contains=officewiki_session
Last-Modified Wed, 20 Jul 2011 17:18:54 GMT
Content-Encoding gzip
Content-Length 20
Age 78
X-Cache HIT from, MISS from
X-Cache-Lookup HIT from, MISS from
Via 1.1 (squid/2.7.STABLE7), 1.0 (squid/2.7.STABLE7)

it looks like the redirect is built fresh, not just cached at least in this case, but it's getting built out with the HTTP form. Either MediaWiki is formatting the Location: URL as HTTP, or the proxies in front of it are expanding it from protocol-relative and doing so as http.

The redirect target appears to be built with WebRequest::getFullRequestURL() which uses $wgServer, which in this case I think ought to be the protocol-relative link.

This then doesn't seem to get expanded further, so it might be nginx (the https proxies) that are expanding it to http:// or else the caches or?

We do though output a 301 here which is meant to be cacheable; so if that happens below the cache layer we could also be caching things incorrectly.

This is an issue with other things as well, such as the redirect after submitting the login form: you log in over https, and after logging you in MW will happily send you to http.

This should be fixed with r93258. Haven't tried this yet though.

Fix confirmed on testwiki, closing.