https://bugzilla.wikimedia.org/show_bug.cgi?id=30294
--- Comment #8 from darklama <darkl...@gmail.com> 2011-08-12 17:34:53 UTC --- (In reply to comment #7) > So I guess what happened is that it was using relative URLs before, which RL > broke, then people switched to using path-absolute URLs (like > /w/index.php?...), which broke on secure? What happened as I understand is all the skin related stuff in /skins-1.5/ that use to be duplicated for each wiki was centralized to bits.wikimedia.org and a load.php script was introduced to bits.wikimedia.org that also loaded the site wide and skin specific CSS and JavaScript for the target wiki and user. Relative URLs like /w/index.php in MediaWiki:Common.css and in other places began to point to bits.wikimedia.org/w/index.php instead which broke Relative URLs completely. URL rewriting of relative URLs like /w/index.php into absolute URLs like http://en.wikibooks.org/w/index.php and http://secure.wikimedia.org/wikibooks/en/w/index.php fixed this. Now for some reason relative URL rewriting has /w/index.php pointing to http://secure.wikimedia.org/w/index.php when using secure.wikimedia.org to browse a wiki. This broke relative URL rewriting on secure. I hope this answers that question. > How recently did this start breaking? AFAIK it broke August 9th 2011, the same day it was first reported at Wikibooks and to Bugzilla. However due to browser caching could maybe have been as long as July 9th 2011. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
