Author: sumanah
Description:
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.
Version: unspecified
Severity: normal
| 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 |
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.
sumanah wrote:
I no longer encounter this problem on office.wikimedia so I'm closing this.