Or is it blocking on isaacs/github#156?

Use CloudFlare?

I'm fine with using CloudFlare, but I don't know how it's meant to be used with GitHub Pages.

Googling for github pages cloudflare finds this recent article:

https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/

Thanks for the suggestion!

Was OK on https (IFAICR)

Currently showing an error. Did you end up using CloudFlare in the end, or sticking with LetsEncrypt ?

I don't think it ever worked. There wasn't any action taken yet.

Could we make it work at https://gopherjs.github.io/playground/ until github supports HTTPS for custom domains ? Right now, this redirects to http://www.gopherjs.org/playground but if we could avoid this redirection, that would be a first step.

Then the connection to the snippet server would also have do be done over HTTPS in order to avoid mixed content errors, but there is also a certificate problem with this server: https://snippets.gopherjs.org presents a certificate issued for gotools.org and www.gotools.org instead of snippets.gopherjs.org.

Then the connection to the snippet server would also have do be done over HTTPS in order to avoid mixed content errors, but there is also a certificate problem with this server:

That's not a blocking problem, I can make snippet server support HTTPS as soon as the first step is done.

Could we make it work at https://gopherjs.github.io/playground/ until github supports HTTPS for custom domains ?

Isn't that what this issue is about? Do you know how that can be done? I don't know of a way. It's GitHub Pages, which I don't know how to make use HTTPS.

Edit: Ah, I didn't notice that you mentioned https://gopherjs.github.io/playground/, which is not the same as https://www.gopherjs.org/playground/ which the original issue was about.

Oh, apparently there's been an update at isaacs/github#156 since I created this issue in 2015. There's now:

https://github.com/blog/2186-https-for-github-pages

So it should be possible, at least for https://gopherjs.github.io/playground/!

The only (minor?) issue with that is that it's not the canonical URL of the playground.

https://help.github.com/articles/securing-your-github-pages-site-with-https/ says HTTPS is not supported for GitHub Pages using custom domains..

I would not be opposed to dropping the custom domain.

Apparently the redirection https://gopherjs.github.io/playground => http://www.gopherjs.org/playground occurs as soon as a custom domain is set: https://help.github.com/articles/custom-domain-redirects-for-github-pages-sites/
It does not seem possible to disable it while keeping the custom domain.

A few points to consider:

• Once/If the custom domain is disabled and we switch to gopherjs.github.io/playground, HTTPS may be enforced by GitHub (see https://help.github.com/articles/securing-your-github-pages-site-with-https/) and right now this would break the playground because of mixed content and wrong certificate for snippets.gopherjs.org. It could a good idea to fix those 2 problems first (This shouldn't break anything in the current playground, it's not a problem to load HTTPS resources on a HTTP page).
• It would be nice that the old URLs still redirect to the new playground address (http://www.gopherjs.org/playground/#/FOO => http://gopherjs.github.io/playground/#/FOO). I saw the following page describing a way to have custom redirect: https://help.github.com/articles/redirects-on-github-pages/. But given the fact the opposite redirection (http://gopherjs.github.io/playground=>http://www.gopherjs.org/playground) is in place right now, we have to be careful not to create a redirection loop.

It could a good idea to fix those 2 problems first (This shouldn't break anything in the current playground, it's not a problem to load HTTPS resources on a HTTP page).

It would take me a few minutes to fix that... Ok, might as well. I've done that. Now https://snippets.gopherjs.org/p/hy-CTQOoiM and http://snippets.gopherjs.org/p/hy-CTQOoiM both work.

Before we move forward, I'm also not extremely attached to the http://www.gopherjs.org domain name (also because I don't like the www. prefix in front) and I'm okay with https://gopherjs.github.io. That said, I do feel that gopherjs.org/playground feels nice and I'm not sure if losing that as the canonical playground URL is a good idea...

it's not a problem to load HTTPS resources on a HTTP page

Oh, is that so? Then I'd happily drop http support for snippets.gopherjs.org (by having it redirect to https).

The only reason I made snippet.gopherjs.org work over HTTP is because I thought we had to. I actually had to go out of my way to make it work (my HTTP router is otherwise nothing more than a redirector to HTTPS).

Oh, is that so?

Yes, I can confirm this point. Mixed content only applies to HTTP resources loaded from a HTTPS page, not the other way around. Here are a few references:
https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
https://developers.google.com/web/fundamentals/security/prevent-mixed-content/what-is-mixed-content
http://stackoverflow.com/q/20516584

Thank you. I'll make a PR (edit: made #62) to update playground to always use HTTPS to access snippet store, since it sounds like we can make that part of the upgrade seamlessly now in a completely backwards compatible way. Then I can get rid of the machinery for HTTP snippet server support. :D

There is still a little problem (e.g. when you load https://www.gopherjs.org/playground/#/X98vxh8Y97 and accept the certificate warning):
XMLHttpRequest cannot load https://snippets.gopherjs.org/p/X98vxh8Y97. The 'Access-Control-Allow-Origin' header has a value 'http://www.gopherjs.org' that is not equal to the supplied origin. Origin 'https://www.gopherjs.org' is therefore not allowed access.
It looks like the snippet store only allows requests coming from http://www.gopherjs.org and not from https://www.gopherjs.org.

It looks like the snippet store only allows requests coming from http://www.gopherjs.org and not from https://www.gopherjs.org.

Yes, it currently does. See https://github.com/gopherjs/snippet-store/blob/af71d7b00e2cbe970396736b6135e90d890d9c1b/main.go#L23.

I'll change it to support both http://www.gopherjs.org and https://www.gopherjs.org.

It seems you can't statically set that header to multiple domains. Instead, you need to dynamically see where the request is coming from, and if it's one of the allowed domains, set Access-Control-Allow-Origin to that.

See http://stackoverflow.com/questions/1653308/access-control-allow-origin-multiple-origin-domains.

I'm not sure if it's worth doing that now, since https://www.gopherjs.org cannot be practically used at this time (due to the certificate warning).

Although if I read the spec, https://www.w3.org/TR/cors/#access-control-allow-origin-response-header, suggests:

Access-Control-Allow-Origin = "Access-Control-Allow-Origin" ":" origin-list-or-null | "*"

And origin-list-or-null is:

   origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
   origin-list         = serialized-origin *( SP serialized-origin )
   serialized-origin   = scheme "://" host [ ":" port ]
                       ; <scheme>, <host>, <port> from RFC 3986

So this should work:

Access-Control-Allow-Origin: http://www.gopherjs.org https://www.gopherjs.org

However, it might be still the case that not all browsers implement the spec fully, according to http://stackoverflow.com/a/12818477/622447.

Edit: I think that's not what the spec says. See http://stackoverflow.com/a/25517194/622447.

I think this issue is fully resolved now, is it not?

The website is fully https and redirects from http to https.

Yes, it's working well, great job !