Last modified: 2013-12-05 20:54:36 UTC
The link URL is protocol-relative, the image src is always https. Given that we want to encourage safe browsing of Wikimedia sites, I would go with https for both.
(In reply to comment #0) > Given that we want to encourage safe browsing of Wikimedia sites, I would go > with https for both. This would be like asking the people over at en.wp "please, please, hate me!". I suggest you don't do that. :)
Why is that? Registered users are redirected to HTTPS after login anyway.
Only if they don't change a preference. People changed that preference and will be mad if you ignore it. Whether they are sane or not doing this doesn't matter.
We can check with other teams on this point, but I think the foundation is generally behind 'https' as a safer alternative for the hundreds of millions of users we serve daily. We don't have to do this right away, as I would like to get more input from other teams, to make sure we're all on the same page.
We are ignoring it either way, just in a different direction; not ignoring it is not a possibility. If we use a protocol-relative link (or more precisely the 3rd party who copies the snippet from MediaViewer does), and someone would prefer HTTPS, but clicks on the image on a site which itself does not support HTTPS, we have broken his expectations. So there is no perfect solution, but expecting HTTPS and ending up with HTTP can be dangerous, while the reverse is at worst uncomfortable, so HTTPS is the better option. A more serious problem is that MediaViewer should be able to serve 3rd-party wikis as well, some of which might not support HTTPS at all... not sure what could be the solution to that.
I might have misunderstood how the links are used, sorry. The solution to all of those issues it to use wfExpandUrl(), with no additional arguments for URLs used e.g. in <a href="">, and with PROTO_CANONICAL for URLs e.g. placed in text boxes for copying. This function will correctly use $wgServer and $wgCanonicalServer configuration settings to make the links work they way we've all grown to expect.
This has to be done in client-side code, and the URL is not necessarily a local one (the lightbox could be on enwiki, while the image could nbe hosted on Commons); more importantly, that logic would result in using HTTP or HTTPS based on the preference of the user who is clicking at the use file button. That user will use the snippet to share the image on his blog or something, and has nothing to do with the user who clicks on that shared image to go to the file description page on Wikipedia. There is just no way to respect the latter user's preferences, so we might as well disrespect it in the more useful direction.
[restoring priority]
This shouldn't be a hard fix, it should just be a simple change to the way the URLs are constructed.
A Google Code-in student has claimed this task: http://www.google-melange.com/gci/task/view/google/gci2013/5868509229744128
The problem should come from the src or link variable because it may be assigned to something like this "images/logo.png". This means the image wil be loaded via http or https depending on the URL used in the browser.
Looking at deployed MV right now, the file page URL is actually just relative, not even proto-relative (<a href="/wiki/File:...">), which obviously doesn't make sense here.
Change 98180 had a related patch set uploaded by Brian Wolff: Bug:56787 Corrected the page link and the problem if the link is to a remote server and some problems https://gerrit.wikimedia.org/r/98180
Got a bit lost in the Gerrit changeset. Can this GCI task be closed as completed, or are we still waiting for a fix from vldandrew?
Change 98180 merged by jenkins-bot: Corrected page link and problems if the link is to a remote server https://gerrit.wikimedia.org/r/98180
OK, we should be set now. If there are further issues they can be addressed going forward, maybe as part of this bug, but I think we're fairly consistent now.
