Page MenuHomePhabricator

Protocol-relative URLs in ResourceLoader (CSSMin)
Closed, ResolvedPublic

Description

CSSMin expands URLs to images and such when it does path rewriting. It also runs these paths through wfExpandUrl(), which means they will usually end up starting with http:// (even with a protocol-relative $wgServer). We can't use magic request protocol-based switching between http and https either due to caching, so we should just output protocol-relative (or even URLs relative to the root? I think there's a reason we don't do that but I forget) URLs here.

Reported by GreenReaper (CC).


Version: 1.20.x
Severity: normal

Details

Reference
bz29969

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:35 PM
bzimport set Reference to bz29969.
Catrope created this task.Jul 19 2011, 8:40 PM

To provide further insight on caching, my use case is:

Apache (serving privately on http port 81)
talking to
Varnish (serving publicly on port 80) - Squid could be here too
with
Pound (serving publicly on port 443, directing requests to the Varnish cache)

Preferably there would be no need to cache separate HTTP and HTTPS copies, or even let Apache know that the request is HTTPS (Varnish is told this via an X-HTTPS header to allow it to handle some redirects appropriately).

(In reply to comment #1)

Preferably there would be no need to cache separate HTTP and HTTPS copies,

I agree, that's what we're also aiming for for our future WMF HTTPS setup.

or
even let Apache know that the request is HTTPS (Varnish is told this via an
X-HTTPS header to allow it to handle some redirects appropriately).

On WMF, MediaWiki will be aware of that it's being invoked over HTTPS (it needs to be, to send secure cookies) using X-Forwarded-Proto. Other than that, our SSL termination setup is similar to yours.

Whoops, this actually already works for me. I have $wgStylePath and
$wgExtensionAssetsPath set to protocol-relative URLs, and GreenReaper didn't.

Not true! $wgStylePath was protocol-relative. $wgExtensionAssetsPath wasn't set at all. I tried setting it and it didn't seem to make any difference (not that I'd expect it to for a wiki-sourced CSS file anyway).

Now, I'm using this on 1.17, so maybe this has been fixed in the meantime.

Strange. I also have $wgServer set to a protocol-relative URL, which will make your wiki explode on 1.17 or lower. Maybe it's that, or maybe something changed.