Last modified: 2013-06-18 13:47:37 UTC
I'm logged into an https site (office.wikimedia.org) and I hit Edit to edit a page. I make a change to save the page, and find myself on the http version, and get an error message telling me I'm not logged in so my edit can't go through.
This'll be the same base problem as bug 29981 -- when saving, you first POST to a local link (so HTTPS -> HTTPS) and then after processing, it redirects you to a GET on the article. It'd be that redirection where we're losing the https.
This can probably be fixed by dropping a wfExpandUrl() onto the redirection URL prior to sending it out; unlike the URL normalization redirects it doesn't need to be cached, so there's no worry here about cache corruption.
(In reply to comment #2) > This can probably be fixed by dropping a wfExpandUrl() onto the redirection URL > prior to sending it out; unlike the URL normalization redirects it doesn't need > to be cached, so there's no worry here about cache corruption. Actually it's probably wfExpandUrl() that's *causing* this in the first place. This is because, currently, wfExpandUrl( '//example.com' ) always returns 'http://example.com' regardless of which protocol the request came in on. The function needs this mode to avoid cache pollution, but I guess it also needs an 'expand to whichever protocol was used for this request' mode.
I no longer encounter this problem on office.wikimedia so I'm closing this.
