Last modified: 2014-02-19 21:19:52 UTC
As has been poked around the lists for a while, there's some interest in more active use of protocol-relative URLs (eg, '//upload.wikimedia.org/path/to/file.png' instead of 'http://upload.wikimedia.org/path/to/file.png'). Touted benefits include: * ability to reference on-site links, sister-site links, and sister-site media references with the current protocol without having to render and cache separately for HTTP and HTTPS (but this requires that the URLs be otherwise identical! Would not be compatible with our current secure.wikimedia.org scheme, for instance) * saving 5-6 bytes each for many of those external URL references Browser compatibility seems reasonably stable for those who have been testing it, but there are lots of gotchas as MediaWiki doesn't cleanly support this yet. A few notes offhand: * wfExpandUrl and numerous other places assume any URL starting with "/" is relative to the current _host_ and will prepend '$wgServer' to it. * there will be various places where we need to explicitly use a complete URL including the protocol, such as when creating emails, HTML or RSS feeds to use externally * Uses of {{fullurl:}} {{SERVER}} etc in wikitext assume that the result is ok for use in wikitext as links; currently I don't believe these will get picked up. In general we also probably want MW to know when it needs to make an HTTP reference and when an HTTPS reference, and generate those explicitly at times. (Eg a login link should always be HTTPS; some interwikis might take both HTTP and HTTPs while others might only take one or the other.)
Fixed up wfExpandUrl() to accept protocol-relative URIs in r63848.
Relevant IE bug: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/ IE7 and 8 will download stylesheets with protocol-relative URLs twice. Weird, but true. It's fixed in IE9: http://blogs.msdn.com/b/ieinternals/archive/2010/09/15/ie9-beta-minor-change-list.aspx
Re, the double load bug in IE. It sounds like it's not _that_ bad of an issue, since it only happens when the resource is not cached (on the first request): According to Eric Lawrence from Microsoft: "The reason that the problem appears intermittently isn’t related to Fiddler, but instead to timing. Internal to Trident, the download queue has “de-duplication” logic to help ensure that we don’t download a single resource multiple times in parallel. Until recently, that logic had a bug for certain resources (like CSS) wherein the schema-less URI would not be matched to the schema-specified URI and hence you’d end up with two parallel requests. Once the resource is cached locally, the bug no longer repros because both requests just pull the cached local file."
This seems to be pretty solid now. I've added support for using protocol-relative URLs in wikitext in r91663 and r92005, support for protocol-relative URLs in wfParseUrl() in r92024 and support for protocol-relative values of $wgServer in wfExpandUrl() in r92028. Now it's just a question of expanding URLs in API output (and other non-UI things such as RSS) in a few more places. External link search is probably gonna be broken, but that's bug 29854. This bug can be closed.
I only have two elements left in https://en.wikipedia.org and https://nl.wikipedia.org <link rel="apple-touch-icon" href="http://en.wikipedia.org/apple-touch-icon.png" /> and <div class="printfooter"> Retrieved from "<a href="http://en.wikipedia.org/wiki/Special:Watchlist">http://en.wikipedia.org/wiki/Special:Watchlist</a>"</div>
@Derk-Jan Hartman: wgAppleTouchIcon has been fixed and deployed. The latter is imho a pending WONTFIX. It is only shown on print, and on print canonical URLs are used.
