https://bugzilla.wikimedia.org/show_bug.cgi?id=52253
--- Comment #3 from MZMcBride <[email protected]> --- (In reply to comment #0) > Protocol-relative URLs might be various kinds of awesome, and they work with > every major browser. This bug somewhat annoyingly fails to mention why protocol-relative URLs are being used. Bug 20342 comment 0 gives a decent overview of why protocol-relative URLs were implemented on Wikimedia wikis. In reality, most (see rough stats below) URLs in articles are simply relative ("/wiki/Foo" or "/w/index.php?title=Foo"), not protocol-relative ("//wikiproject.org/w/index.php?title=Foo"). Resources (bits.wikimedia.org and upload.wikimedia.org) rely on protocol-relativity more than anything else (sending mixed content causes ugly warnings in browsers). Switching bits and upload to always be HTTPS would resolve a good portion of the issue being discussed here. A few minor edits to interface messages would also go a long way in resolving most of this bug. (In reply to comment #1) > I'm tempted to say this is an issue with said badly written clients, not > MediaWiki, and therefore this is invalid... We sometimes accomodate stupid clients (as well as stupid users, for that matter). I'm was somewhat inclined to say that this bug is a duplicate of bug 20342 ("Support for protocol-relative URLs (tracking)") or bug 47832 ("Force all Wikimedia cluster traffic to be over SSL for all users (logged-in and anon)"), but assuming the numbers I ran below are correct, this bug could simply be a tracking bug with a few (relatively easy) dependencies. --- Recently featured articles on the English Wikipedia [[Main Page]]: * [[Barber coinage]] * [[Harold Davidson]] * [[War of the Bavarian Succession]] For [[Barber coinage]]: $ curl -s --compressed "https://en.wikipedia.org/wiki/Barber_coinage"; | grep -o '="//' | wc -l 76 $ curl -s --compressed "https://en.wikipedia.org/wiki/Barber_coinage"; | egrep -o '="/[^/]' | wc -l 330 For [[Harold Davidson]]: $ curl -s --compressed "https://en.wikipedia.org/wiki/Harold_Davidson"; | grep -o '="//' | wc -l 46 $ curl -s --compressed "https://en.wikipedia.org/wiki/Harold_Davidson"; | egrep -o '="/[^/]' | wc -l 233 For [[War of the Bavarian Succession]]: $ curl -s --compressed "https://en.wikipedia.org/wiki/War_of_the_Bavarian_Succession"; | grep -o '="//' | wc -l 91 $ curl -s --compressed "https://en.wikipedia.org/wiki/War_of_the_Bavarian_Succession"; | egrep -o '="/[^/]' | wc -l 362 Summary: * [[Barber coinage]]: 81.28% of links are simply relative; of the protocol-relative links (76), 71.05% are from bits (18) or upload (36) * [[Harold Davidson]]: 83.51% of links are simply relative; of the protocol-relative links (46), 63.04% are from bits (15) or upload (14) * [[War of the Bavarian Succession]]: 79.91% of links are simply relative; of the protocol-relative links (91), 56.04% are from bits (15) or upload (36) Of the protocol-relative links, there are lots of very low-hanging fruit that could easily be made to always use HTTPS that are deflating the numbers directly above. For example: * <a href="//wikimediafoundation.org/wiki/Privacy_policy" title="wikimedia:Privacy policy">Privacy policy</a> [twice] * <a href="//en.wikipedia.org/wiki/Wikipedia:Contact_us">Contact Wikipedia</a> * <a href="//wikimediafoundation.org/"><img src="//bits.wikimedia.org/images/wikimedia-button.png" width="88" height="31" alt="Wikimedia Foundation"/></a> * <a href="//www.mediawiki.org/"><img src="//bits.wikimedia.org/static-1.22wmf11/skins/common/images/poweredby_mediawiki_88x31.png" alt="Powered by MediaWiki" width="88" height="31" /></a> * <a rel="license" href="//en.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License">Creative Commons Attribution-ShareAlike License</a> * <a rel="license" href="//creativecommons.org/licenses/by-sa/3.0/" style="display:none;"></a> * <a href="//donate.wikimedia.org/wiki/Special:FundraiserRedirector?utm_source=donate&utm_medium=sidebar&utm_campaign=C13_en.wikipedia.org&uselang=en" title="Support us">Donate to Wikipedia</a> * <link rel="copyright" href="//creativecommons.org/licenses/by-sa/3.0/" /> These amount to 9 links. Re-running our numbers again, we find: * [[Barber coinage]]: protocol-relative links: 76 bits.wikimedia.org: 18 upload.wikimedia.org: 36 interface: 9 easily eliminated: 82.89% * [[Harold Davidson]]: protocol-relative links: 46 bits.wikimedia.org: 15 upload.wikimedia.org: 14 interface: 9 easily eliminated: 82.61% * [[War of the Bavarian Succession]]: protocol-relative links: 91 bits.wikimedia.org: 15 upload.wikimedia.org: 36 interface: 9 easily eliminated: 65.93% Basically, as I see it, if instead of griping, you simply provisioned a few more resources servers (upload and bits) and submitted a few edits to MediaWiki messages or changesets to Gerrit, you could resolve somewhere between two-thirds and four-fifths of the problem you're describing in comment 0 without breaking a sweat. That number gets even higher (probably somewhere around 90–95%) with an additional single edit to [[m:Interwiki map]] and an adjustment to the interlanguage links output, which make up most of the remaining protocol-relative URLs. For what it's worth. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
