Last modified: 2011-10-06 16:22:35 UTC
As reported on [[wikibooks:Wikibooks:Reading_room/Technical_Assistance#CSS_is_not_loaded_on_secure_server]] rules such as ---- @import url("/w/index.php?title=MediaWiki:Common.css/Infobox.css&action=raw&ctype=text/css") screen; ---- are not working on secure server. They generates errors such as ---- GET https://secure.wikimedia.org/w/index.php?title=MediaWiki:Common.css/Infobox.css&action=raw&ctype=text/css 404 (Not Found) ---- on Google Chrome 13.0.782.107.
How is this ResourceLoader's fault? I don't see how that @import statement would work on the secure server even without ResourceLoader.
Relative URLs are supported just fine by @import, the problem is that that directly (/w) doesn't exist in that location on the secure server. This is one of the many annoying issues with the current secure server configuration. There's currently two projects going on related to this that will make this problem obsolete: * Protocol-relative url support in MediaWiki (ie. //en.wikipedia.org/wiki/Foo, without http or https) * HTTPS for all Wikimedia wikis, natively (ie. https://en.wikipedia.org/ ) Once that is done, @import will also work fine as both secure and non-secure will be the same domain name. Closing as INVALID as this is a problem with the secure server. ResourceLoader and @import are doing just fine.
See bug 27328 which had previously addressed and fixed this issue when ResourceLoader and load.php were first introduced. Could be considered a regression.
(In reply to comment #3) > See bug 27328 which had previously addressed and fixed this issue when > ResourceLoader and load.php were first introduced. Could be considered a > regression. It's not a regression, it's a different case (secure.wm.o-specific) that was probably broken the whole time. The two bugs appear related, but they're not related in the way you think they are. I'm leaving this open because it is a legitimate bug (something is broken), but making it a dependency of the HTTPS tracking bug. Once proper HTTPS is set up and secure dies, this'll be fixed.
No bug 27328 not related at all. '/' means the root of a domain. Loading @import('/w/index.php ...'); works just fine. When you're on en.wikibooks.org, it loads: en.wikibooks.org/w/index.php. The problem is that, when you're on secure.wikimedia.org/wikibooks/en/, since / refers to the root of the domain (this is a general HTML/CSS rule, not related to ResourceLoaderor @import specifically), it loads: secure.wikimedia.org/w/index.php (which doesn't exist).
(In reply to comment #4) > It's not a regression, it's a different case (secure.wm.o-specific) that was > probably broken the whole time. The two bugs appear related, but they're not > related in the way you think they are. (In reply to comment #5) > No bug 27328 not related at all. > > '/' means the root of a domain. > > Loading @import('/w/index.php ...'); works just fine. > > When you're on en.wikibooks.org, it loads: en.wikibooks.org/w/index.php. > > The problem is that, when you're on secure.wikimedia.org/wikibooks/en/, since / > refers to the root of the domain (this is a general HTML/CSS rule, not related > to ResourceLoaderor @import specifically), it loads: > > secure.wikimedia.org/w/index.php (which doesn't exist). Well perhaps this wasn't fully understood by the report for bug 27328, but relative URLs did work just fine for secure.wikimedia.org prior to 1.17, ResourceLoader, and load.php as well. The fix that was introduced by bug 27328 had made relative URLs for secure.wikimedia.org work as well again. This wasn't broken the whole time. Something recent caused it to stop working just for secure.wikimedia.org.
(In reply to comment #6) > Well perhaps this wasn't fully understood by the > report for bug 27328, but relative URLs did work > just fine for secure.wikimedia.org prior to 1.17, > ResourceLoader, and load.php as well. The fix > that was introduced by bug 27328 had made > relative URLs for secure.wikimedia.org work as > well again. > 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? > This wasn't broken the whole time. Something > recent caused it to stop working just for > secure.wikimedia.org. By 'the whole time' I meant 'since bug 27328 was fixed'. How recently did this start breaking?
(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.
(In reply to comment #7) > then people switched to using path-absolute URLs (like > /w/index.php?...), which broke on secure? In case I misunderstood this part. We didn't do anything at Wikibooks, /w/index.php just stopped working on secure.
> 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. Afaik, such rewriting has never and does not exist in ResourceLoader for @import. I know that for a certain amount of time wikibooks switched to using _absolute_ urls in their @imports, they probably switched away from it since it would generate http requests on httpS pages, which then broke it again (but only on secure, so perhaps nobody noticed until recently).
(In reply to comment #10) > Afaik, such rewriting has never and does not exist in ResourceLoader for > @import. Maybe /includes/libs/CSSMin.php isn't considered part of ResourceLoader any more. I know it was originally part of the ResourceLoader branch though as the SVN revision history shows. [1] > I know that for a certain amount of time wikibooks switched to using _absolute_ > urls in their @imports, they probably switched away from it since it would > generate http requests on httpS pages, which then broke it again (but only on > secure, so perhaps nobody noticed until recently). Yes Wikibooks switched from relative to absolute URLs for a short while back in February 2011 when bug 27328 was first noticed. Wikibooks switched back when the fix was introduced. I made sure the fix actually worked myself both for http and for https secure by deleting my browser cache and checking where firebug was looking for the @import requests. This isn't a case of not noticing it was broke for 6 months. That much I am sure about. [1] http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/libs/CSSMin.php?view=log&pathrev=82457
Hmm, I'm wondering whether it's possible that the recent het deploy changes changed what $wgServer is on secure?
(In reply to comment #12) > Hmm, I'm wondering whether it's possible that the recent het deploy changes > changed what $wgServer is on secure? That sounds like a plausible explanation to me. I haven't been able to find another explanation yet by looking through code revisions.
CC Aaron Schulz, who's doing the het deploy stuff.
FYI: The problem is also happening on Wikimedia Commons, since [[commons:MediaWiki:Common.css]] has the following: ---- @import url("/w/index.php?title=MediaWiki:Common.css/Mboxes.css&action=raw&ctype=text/css") screen; ---- This causes Chromium 12.0.742.112 (90304) Ubuntu 11.04 to display in the error console: ---- Failed to load resource: the server responded with a status of 404 (Not Found) ----
Did a little research on commonswiki: 1) When loaded through http://commons.wikimedia.org - The site-css module is loaded through the following url: http://bits.wikimedia.org/commons.wikimedia.org/load.php?debug=false&lang=en&modules=site&only=styles&skin=vector - @import url("/w/index.php was expanded to @import url("http://commons.wikimedia.org/w/index.php 2) When loaded through https://secure.wikimedia.org/wikipedia/commons/wiki - The site-css module is loaded through the following url: https://secure.wikimedia.org/wikipedia/commons/w/load.php?debug=false&lang=en&modules=site&only=styles&skin=vector - @import url("/w/index.php was expanded to @import url("https://secure.wikimedia.org/w/index.php 3) When loaded through the experimental https://commons.wikimedia.org it's the same as 1) - site-css from bits - expanded to http (not https)://commons.wikimedia.org/w/index.php
(In reply to comment #16) > 3) When loaded through the experimental https://commons.wikimedia.org it's the > same as 1) > - site-css from bits > - expanded to http (not https)://commons.wikimedia.org/w/index.php That's a bug, but it's probably due to commonswiki not having a protocol-relative $wgServer. Could you try this one on wikimania2005wiki and see what you get there?
(In reply to comment #17) > That's a bug, but it's probably due to commonswiki not having a > protocol-relative $wgServer. Could you try this one on wikimania2005wiki and > see what you get there? 3) When loaded through the experimental https://test.wikipedia.org: - site-css from https://bits - expanded to https://test.wikipedia.org/w/index.php - wgServer: //test.wikipedia.org
This is a problem due to the configuration. You have the same problem with javascript, but when loading javascript you can use $wgScript, which has the right value in case of the secure server. When using $wgScript you avoid the hardcoded /w/index.php. But in style sheets you cannot use $wgScript, you have no change to make a different import statement for http/https with the current configuration of WMF wikis. You can load the style sheets per javascript. It is not a bug, because under https://secure.wikimedia.org/w/index.php are nothing (that is the 404), because you find the content under https://secure.wikimedia.org/wikipedia/commons/w/index.php. You want an enhancement for the ResourceLoader: Supporting a simple syntax for $wgScript in import statements of style sheets.
This now appears to be working for mediawiki 1.18 when using https://en.wikibooks.org as was described in comment #2
