Author: sumanah
Description:
On office.wikimedia.org, if I'm on the unsecure site
http://office.wikimedia.org/wiki/Main_Page
and then click on the banner link to https://office.wikimedia.org/ , I get directed to
http://office.wikimedia.org/wiki/Main_Page
I'm on Firefox 3.6.18. Installed extensions:
Ubuntu Firefox Modifications 0.9rc2 HTTPS-Everywhere 0.9.7 Readability 1.9 Universal Print 0.4.24
Version: unspecified
Severity: normal
OS: Linux
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T32008 "Save page" button redirects from HTTPS to insecure | |||
| Resolved | Catrope | T31981 Location: redirects on https sites always point to http sites |
I assume the link you're clicking is the https://office.wikimedia.org/ 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:
https://office.wikimedia.org/wiki/Main%20Page
also gets redirected to:
http://office.wikimedia.org/wiki/Main_Page
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
Location http://office.wikimedia.org/wiki/Main_Page
Content-Encoding gzip
Content-Length 20
Age 78
X-Cache HIT from sq62.wikimedia.org, MISS from sq40.wikimedia.org
X-Cache-Lookup HIT from sq62.wikimedia.org:3128, MISS from sq40.wikimedia.org:80
Via 1.1 sq62.wikimedia.org:3128 (squid/2.7.STABLE7), 1.0 sq40.wikimedia.org:80 (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.