Last modified: 2014-02-12 23:32:53 UTC
The last line of ResourceLoader::makeLoaderURL() contains a call to wfAppendQuery() wrapped in a call to wfExpandUrl(). The effect is to create a URL to load.php that contains descriptions of resources -- which it does: a fully-qualified URL with the protocol. In most cases this works fine, but the protocol observed by the server is not guaranteed to be the same as the protocol submitted by the client because of various things like load-balancers, proxies, etc. In our enterprise environment, SSL is terminated at the load-balancer. However, for Special:UserLogin we force HTTPS (to avoid security implications with clear-text passwords.) When Special:UserLogin loads, the HTML response is loaded over HTTPS, but it contains HTTP links to load.php -- which fail on some browsers which do not load mixed-protocol content. ( Chrome :/ ) Arguably this is a bug with wfExpandURL() and not the ResourceLoader, but this is where it manifested itself first. The solution which would preserve current behavior while enabling desirable behavior is a simple configuration variable: $wgForceRelativeUrls. When set to true, wfExpandURL() would just return its first parameter (the relative url.) Possible duplicate of Bug 29969
The intent of makeLoaderURL() is to generate domain-relative URLs of the form /w/load.php?.... Looks like that broke at some point.
You're right Roan. Although the ResourceLoader emits fully-qualified URLs instead of domain-relative URLs, my opinion is that this should be done for all of MW. (There's probably some arcane reason why it isn't, and I just don't know about said reason.)
At Wikimedia HTTPS is implemented through a cluster of NGINX nodes in front of the cluster that serves all HTTP requests (using Apache in our case). Though this may change, the principle sounds similar to yours. This is among the reasons we use protocol-relative urls so that the cache can be shared. So for www.mediawiki.org and en.wikipedia.org for example: $wgServer = '//www.mediawiki.org'; Also note that there is $wgCanonicalServer and $wgInternalServer which can come in handy.
I left it out here (implied), but maybe I should make it explicit: MediaWiki supports protocol-relative urls very well. It was a major thing in MediaWiki 1.18[1], which is around the time Wikimedia started using native HTTPS support on all domains. In fact, the method you refer to (ResourceLoader::makeLoaderURL) explicitly orders wfExpandUrl to allow the url to be relative (instead of expanding to http:// or https:// ), by passing PROTO_RELATIVE. PROTO_RELATIVE tells wfExpandUrl to keep the url relative if the MediaWiki configuration indicates that the server supports both, which you do by setting $wgServer to a protocol-relative url of the host name. Otherwise, for things that need t be a full furl including protocol, $wgCanonicalServer is used (defaults to HTTP). [1] https://www.mediawiki.org/wiki/MediaWiki_1.18
I guess I never knew that Mediawiki supported relative-URLs. After digging through the WebRequest class and having a closer look at wfExpandURL() it seems obvious. I never realized you could set $wgServer, I just assumed it was always dynamically generated. In my case, since I only want to force HTTPS for a single page (Special:UserLogin,) my extension just does a str_replace() on $wgServer at the right time under the right conditions. I can see the usefulness in setting $wgServer to a relative URL in LocalSettings, however. I've closed this as INVALID since it's not really a bug, and written a bit of documentation: http://www.mediawiki.org/w/index.php?title=Manual%3A%24wgServer&diff=674744&oldid=664348 Thanks Roan, Timo.
