Last modified: 2011-07-19 22:48:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T31969, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 29969 - Protocol-relative URLs in ResourceLoader (CSSMin)
Protocol-relative URLs in ResourceLoader (CSSMin)
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.20.x
All All
: Unprioritized normal (vote)
: ---
Assigned To: Roan Kattouw
:
Depends on:
Blocks: 20643
  Show dependency treegraph
 
Reported: 2011-07-19 20:40 UTC by Roan Kattouw
Modified: 2011-07-19 22:48 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Roan Kattouw 2011-07-19 20:40:21 UTC
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).
Comment 1 Laurence 'GreenReaper' Parry 2011-07-19 20:48:55 UTC
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).
Comment 2 Roan Kattouw 2011-07-19 20:58:18 UTC
(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.
Comment 3 Roan Kattouw 2011-07-19 21:30:07 UTC
Whoops, this actually already works for me. I have $wgStylePath and
$wgExtensionAssetsPath set to protocol-relative URLs, and GreenReaper didn't.
Comment 4 Laurence 'GreenReaper' Parry 2011-07-19 21:46:21 UTC
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.
Comment 5 Roan Kattouw 2011-07-19 22:48:12 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links