Page MenuHomePhabricator

CSS @import should support relative urls on secure server
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: normal
URL: https://secure.wikimedia.org/wikibooks/en/w/index.php?title=Wikibooks:Reading_room/Technical_Assistance&oldid=2155688#CSS_is_not_loaded_on_secure_server

Details

Reference
bz30294

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:58 PM
bzimport set Reference to bz30294.
bzimport added a subscriber: Unknown Object (MLST).

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.

darklama wrote:

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).

darklama wrote:

(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?

darklama wrote:

(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.

darklama wrote:

(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).

darklama wrote:

(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?

darklama wrote:

(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

  1. 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

  1. When loaded through the experimental https://commons.wikimedia.org it's the same as 1)
  2. site-css from bits
  3. expanded to http (not https)://commons.wikimedia.org/w/index.php

(In reply to comment #16)

  1. 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?

  1. When loaded through the experimental https://test.wikipedia.org:
  2. site-css from https://bits
  3. expanded to https://test.wikipedia.org/w/index.php
  4. 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.

darklama wrote:

This now appears to be working for mediawiki 1.18 when using https://en.wikibooks.org as was described in comment #2