Page MenuHomePhabricator

'https:' prepended to relative paths going through RL, even when the site doesn't support https
Closed, ResolvedPublic

Description

Do some

background-image: url(whatever.svg);

in your css module and it comes out like

background-image: url(https:/w/extensions/whatever/whatever.svg);

Only it seems to do this regardless of what protocol the rest of the site is/supports and results in no image on sites lacking ssl?

Event Timeline

Isarra created this task.Nov 20 2020, 6:22 AM
Restricted Application added a project: Performance-Team. · View Herald TranscriptNov 20 2020, 6:22 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Isarra added a subscriber: ashley.Nov 20 2020, 6:39 AM

@ashley did some digging and found cd54c03e86e6a2a0caa6c6943b22dfa052e874bd, which appears to be responsible.

In "general" local file paths in CSS do not come out that way. I'll need a bit more information about your config and the module in question to narrow this down.

Does the site in question generally still work? E.g. the various uses of relative/local file paths in core extensions that reference a PNG or SVG file, are those also broken?

What do these look like? $wgServer, $wgScriptPath, $wgResourceBasePath, $wgExtensionAssetsPath, $wgStylePath.

What class of module is used here, a plain ResourceLoaderFileModule defined in extension.json, or something else?

Krinkle triaged this task as Unbreak Now! priority.Nov 24 2020, 7:18 PM

Okay, I spoke too soon. I can now reproduce this consistenty on my localhost and also on Beta Cluster. On the latter, the icons seem to work due to an unintentional feature where by a domain-less URL with a scheme in front is interpreted as path URL, which is definitely not intentional.

The main issue is that the domain is missing. The protocol just comes along for the ride for internal relative protocol URL expansion, which will be stripped again once the domain is inserted correctly.

Gilles assigned this task to Krinkle.Nov 24 2020, 7:57 PM
Gilles moved this task from Inbox to Doing on the Performance-Team board.

Change 643383 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] resourceloader: Fix malformed "https:/w/resources" mapping in CSSMin

https://gerrit.wikimedia.org/r/643383

Change 643383 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: Fix malformed "https:/w/resources" mapping in CSSMin

https://gerrit.wikimedia.org/r/643383

Change 643160 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@wmf/1.36.0-wmf.19] resourceloader: Fix malformed "https:/w/resources" mapping in CSSMin

https://gerrit.wikimedia.org/r/643160

Change 643161 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@wmf/1.36.0-wmf.18] resourceloader: Fix malformed "https:/w/resources" mapping in CSSMin

https://gerrit.wikimedia.org/r/643161

Whooo thanks!

Change 643161 merged by jenkins-bot:
[mediawiki/core@wmf/1.36.0-wmf.18] resourceloader: Fix malformed "https:/w/resources" mapping in CSSMin

https://gerrit.wikimedia.org/r/643161

Mentioned in SAL (#wikimedia-operations) [2020-11-25T20:49:24Z] <krinkle@deploy1001> Synchronized php-1.36.0-wmf.18/includes/libs/CSSMin.php: I26ed3e5e9a - fix T268308 (duration: 00m 59s)

Krinkle closed this task as Resolved.Nov 25 2020, 9:00 PM