This is marked as "in beta testing" because the nginx config for our frontends shipped to beta, but we still need to set up certificates and configure the load balancers to actually enable https:// on beta.

I've not bothered with scheme relative links as the tickets asks for. Instead, I've configured nginx to set HTTPS correctly, as ocharles describes.

commit 08eb69fcf1081cd0adb4a75abac91a48633769a6 in musicbrainz server.
commit 5215a888130a42d8e1a5cd9d950de2433f741db5 in the nginx configuration (test only).

If you add this line:

fastcgi_param HTTPS on;

Everything works correctly. X-Forwarded-Port is for a reverse-proxy situation, which we're not in as we use FastCGI. Setting this to 1 unconditionally means that we'll always force https, which might not be what we want.

Test has Catalyst 5.9, so that doesn't seem to be the problem.

Oliver: We are setting the catalyst variable, but we weren't setting the X-Forwarded-Port at the frontend. Unfortunately, it doesn't seem to have worked, at least yet – what version of Catalyst is test.musicbrainz.org running, I wonder?

Thanks for the tip, Oliver ! That's interesting to know.

@Ian: that's odd, we should be setting that to true anyway (as we do have a front end proxy).

It's perfectly valid - http://stackoverflow.com/questions/550038/is-it-valid-to-replace-http-with-in-a-script-src-http

I've never seen links starting with //.
What is this (._.?) Do you have examples ?

http://stackoverflow.com/questions/1664816/is-there-a-way-to-force-c-uri-for-in-catalyst-to-generate-a-uri-that-begins-wi seems to suggest how to make this work for c.uri_for, which is at least what our CSS/JS is done with.