Wikimedia Bugzilla is closed!

*** Bug 6979 has been marked as a duplicate of this bug. ***

May be possible to generate a second set with the alternate links, then load from a different 
cache in $secure mode.

Another interwiki links problem:image.Every image all located at
[http://upload.wikimedia.org]

for example an image in
https://secure.wikimedia.org/wikipedia/zh/wiki/%E4%B8%AD%E9%8A%80%E9%A6%99%E6%B8%AF

-adress:https://secure.wikimedia.org/wikipedia/zh/wiki/Image:185324_4717_raven.jpg
-location:http://upload.wikimedia.org/wikipedia/commons/thumb/e/e3/185324_4717_raven.jpg/120px-185324_4717_raven.jpg
-description:https://secure.wikimedia.org/wikipedia/zh/wiki/Image:185324_4717_raven.jpg

secure also contains:
		<link rel="apple-touch-icon" href="http://en.wikipedia.org/apple-touch-icon.png" />
and the footer is generated with internal links to en-wiki: 
<li id="copyright">All text is available under the terms of the <a class='internal' href="http://en.wikipedia.org/wiki/Wikipedia:Text_of_the_GNU_Free_Documentation_License" title="Wikipedia:Text of the GNU Free Documentation License">GNU Free Documentation License</a>...

I've written a client-side workaround using Greasemonkey: http://userscripts.org/scripts/show/26924

Works quite nicely, though there are still occasional corner cases that it misses.  Also, it would be nice to have an actual list of the wikis available via secure.wikimedia.org and their respective paths.  And of course, it would be nice if this bug was actually fixed (though that won't completely obsolete the script, since it also works on hardcoded links in the page content and, if enabled, on links from other sites).

*** Bug 16432 has been marked as a duplicate of this bug. ***

The following can be used in some cases:

{{#ifeq:{{SERVERNAME}}|secure.wikimedia.org
  |[https://secure.wikimedia.org/wikipedia/commons/wiki/File:{{PAGENAMEE}} description page there]
  |[[Commons:File:{{PAGENAMEE}}|description page there]]
}}

courtesy of User:Dispenser.

*** Bug 22255 has been marked as a duplicate of this bug. ***

I had forgotten to note here, that the English Wikipedia now has Javascript [[MediaWiki:Common.js/secure.js]] deployed that tries to correct as many links as possible. An ugly work around, but at least it is something.

Same in German Wikipedia; seems to fix interwiki links automagically now.

Removing the "shell" keyword, since this is marked as blocked by bug 20646, which is a schema change.  My understanding of "shell" these days is for bugs that a typical person with shell access can address without making code changes.

*** Bug 27573 has been marked as a duplicate of this bug. ***

I'm viewing from behind a firewall that blocks some pages accessed insecurely (with little logic as to what is blocked). I constantly have to check whether a link is taking me to secure or insecure sites.

Yep this is very annoying, since there is no automagic link from insecure site to the same page on the secure one. 

I see several bugs mention similar problems, like bug 29053 as well as several duplicates. Is there a hope to change this in mediawiki ("proudly since 2006!") or should we consider javascript hacks permanent, and start deploying them worldwide?

(In reply to comment #14)
> Yep this is very annoying, since there is no automagic link from insecure site
> to the same page on the secure one. 
> 
> I see several bugs mention similar problems, like bug 29053 as well as several
> duplicates. Is there a hope to change this in mediawiki ("proudly since 2006!")
> or should we consider javascript hacks permanent, and start deploying them
> worldwide?
Our ops people are working on a proper HTTPS solution, so people can access the secure sites using URLs like https://en.wikipedia.org instead of the horrible secure.wm.o hack. This will be implemented using protocol-relative URLs (e.g. //en.wikipedia.org/wiki/Foo) for things like images and interwiki links.

Well since it's not advised to host different secure hosts on the same IPs (due to braindead browsers apart from many other reasons, for example those listed in bug 20643) I'm not convinced this will happen soon. (At least JeLuf doesn't seem to see the light, and I tend to second his opinion.)

Nevertheless I'd be happy to see which way we're supposed to head and when do we plan to get there, be that the current ugliness or the future beauty. :-P

(And this bug isn't even ASSIGNED, heh.)

(In reply to comment #16)
> Well since it's not advised to host different secure hosts on the same IPs (due
> to braindead browsers apart from many other reasons, for example those listed
> in bug 20643) I'm not convinced this will happen soon. (At least JeLuf doesn't
> seem to see the light, and I tend to second his opinion.)
> 
> Nevertheless I'd be happy to see which way we're supposed to head and when do
> we plan to get there, be that the current ugliness or the future beauty. :-P
> 
> (And this bug isn't even ASSIGNED, heh.)
Well ops is working on getting this done, even though the bug isn't assigned. I'll ask Ryan to respond when he wakes up.

To ask what might be a really stupid question... Couldn't the secure site and the non-secure site just use two different $wgInterwikiCache db's? Or would that break in all sorts of weird ways.

Not that it matters much if we're going to get shiny https://en.wikipedia.org style secure sites soon. :D

New SSL cluster fixes this

Reopening. That cluster is not live and even on the wiki's were it's on trial (commons, meta) it doesn't work:

https://commons.wikimedia.org/w/index.php?title=Commons:Sandbox&oldid=60159882
Has a link to [[m:Test]], is not going to https://

Removing bug 20646 dependency as this is going to be solved differently (protocol-relative urls inside interwiki table for those that support it, and http or https hardcoded for (third-party) wikis that don't.

With the new relative protocol urls, can this be closed as WONT FIX?

I am closing this bug since secure.wikimedia.org has been dropped and its functionality replaced.

Using relative URL for interwiki links on WikiMedia website is bug 31327 .