Re: [Wikitech-l] Protocol-relative URLs and HTTPS enabled on foundationwiki and commonswiki

On Wed, Aug 31, 2011 at 3:14 PM, Ryan Lane &lt;rlane32(a)gmail.com&gt; wrote: Cooooooooooool!!!!!!!!!!! Main thing I notice off the bat is that interwiki links seem to have been set up to use protocol-relative links that don't actually work yet -- at https://commons.wikimedia.org/wiki/Atlas there's a link "Stielers Handatlas<https://en.wikipedia.org/wiki/en:Stielers_Handatlas>" which ends up linking to the non-working https://en.wikipedia.org/wiki/en:Stielers_Handatlas Note: there is likely a bunch of site CSS, JS, and templates that will Note that existing JS or template code that looks for an 'https' prefix on $wgServer will continue to see the 'https' in 'https://secure.wikimedia.org' but will see only something like '//commons.wikimedia.org' on https://commons.wikimedia.org/ So this should avoid triggering code that explicitly tries to use the secure.wikimedia.org-style alternate paths; but some code that simply decides whether to load from http or https may end up loading things from http by mistake until fixed. In many cases simply using the '//hostname' style URLs will work fine for both the http://commons.wikimedia.org and https://commons.wikimedia.org -- as long as you don't get ahead of yourself and use it for things that aren't available on https yet. ;) Most importantly for now, loading images from '//upload.wikimedia.org' should work; loading local JS code from '//commons.wikimedia.org/...' *should* also work. Please make sure this gets passed around to any commons JS-ers and stylers and templaters to watch out for issues! Another *important* note: "Log me in globally" is still actually Note that this should get fixed once all the sites are running on https, since we can bump all the cookie-setters onto the current protocol. In the meantime, do consider https://commons.wikimedia.org/ to be very experimental! -- brion