brion at pobox
Aug 31, 2011, 3:56 PM
Post #2 of 6
On Wed, Aug 31, 2011 at 3:14 PM, Ryan Lane <rlane32 [at] gmail> wrote:
Re: Protocol-relative URLs and HTTPS enabled on foundationwiki and commonswiki
[In reply to]
> Roan sent out a new set of HTTPS fixes today, which made us confident
> enough to enable protocol-relative URLs and HTTPS on commonswiki and
> foundationwiki. We haven't purged the cache yet for these wikis, so
> it's very likely some pages will point you back to HTTP. We'll be
> purging caches some time soon, but please don't hesitate to try it
> now. Please file bug reports or let Roan or I know of any issues you
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
which ends up linking to the non-working
Note: there is likely a bunch of site CSS, JS, and templates that will
> need to be changed to use protocol relative URLs everywhere. HTTPS has
> a massive long tail :). If you feel like helping out with that, please
> be bold.
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
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
> insecure, even when using HTTPS. It loads the images from each wiki
> using HTTP, which is what sets your cookies (which are also, then sent
> over HTTP). If you use this option, people can still steal your
> cookies; they cannot, however steal your password.
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
Wikitech-l mailing list
Wikitech-l [at] lists