GitHub pages redirect from https to http

chbrown commented 9 years ago

GitHub pages (gh-pages) now have partial HTTPS support (see #156), at least on the github.io domain, but this support is not fully integrated into gh-pages servers.

Issue

GitHub's static pages' Varnish servers redirect some https:// URLs to http://

E.g., when the user requests a URL that points to a directory, but does not use a trailing slash (see Example section below)

Solution

The redirect's protocol should match the request's protocol.

Example

I have a gh-pages repository at https://github.com/linguistics/tls (a conference; no relation to Transport Layer Security), and URLs like the following work as expected:

https://linguistics.github.io/tls/2014tls/

However, when requesting the following URLs, they do not redirect to the page above, but to http://linguistics.github.io/tls/2014tls/

The results above can be confirmed in the browser or on the command line:

$ curl -s -I https://linguistics.github.io/tls/2014tls | grep Location
Location: http://linguistics.github.io/tls/2014tls/

$ curl -s -I https://linguistics.github.com/tls/2014tls/ | grep Location
Location: http://linguistics.github.io/tls/2014tls/

$ curl -s -I https://linguistics.github.com/tls/2014tls | grep Location
Location: http://linguistics.github.io/tls/2014tls

Comments

The *.github.io wildcard certificate, #156, was the hard part (thanks GitHub!). This fix should be easy.

apatrida commented 9 years ago

The redirect also affects when you put a CDN in front of Github pages. One URL error and you end up on the wrong site, and have to build into your pages to redirect back to the CDN in that case. But then it is hard to test on both Github pages and a live CDN at the same time. The redirect should stay on the same domain to add the trailing "/"

chbrown commented 9 years ago

That reminds me that I got a response regarding this issue from "Jamie Murai (GitHub Staff)" on 2014-11-06, which I've pasted below in its entirety:

Hi Chris,

Sorry for the trouble. We don't yet officially support HTTPS on GitHub Pages. While it works in certain situations, we don't recommend relying on it, or promoting your pages using HTTPS URLs.

That said, I'll certainly pass along your feedback to the Pages team.

Cheers, Jamie

dentarg commented 9 years ago

I also emailed GitHub support about this issue and received the following response 2015-02-03:

Apologies for the delay in replying. We’re looking into the issue, however GitHub Pages does not currently offer HTTPS (SSL) support. While third-party services such as CloudFlare, may in some cases be able to provide that functionality to the end user, at this time, we’re not able to offer support for these configurations.

While HTTPS requests may appear to work, our CDN provider is adding and removing the encryption at their end, and then the request is transmitted over the open internet from our CDN provider to our GitHub Pages infrastructure, creating the appearance of trustability.

This is why we do not yet officially support HTTPS for GitHub Pages. We definitely appreciate the feedback and I’ll add a +1 to this item on out internal Feature Request List.

z3ntu commented 8 years ago

Any news yet?

cben commented 8 years ago

The *.github.com redirects happen for all pages, not just directories:

$ curl -s -I https://linguistics.github.com/tls/2014tls/index.html | grep Location
Location: http://linguistics.github.io/tls/2014tls/index.html

But that's pretty OK, we just shouldn't use the grandfathered .com addresses (they're also slower), use .io everywhere. The directories on .io redirect is truly a problem.

RomanHotsiy commented 8 years ago

It redirects files as well:

$ curl -s -I https://apis-guru.github.io/api-models/api/v1/list.json | grep Location
Location: http://apis.guru/api-models/api/v1/list.json

Does anyone know any workaround for this?

cben commented 8 years ago

Ouch. Apparently if you have a CNAME file, github now redirects all github.io to that domain, with http :-( I'm pretty sure this is new behavior? Don't see anything on github's blog, and wayback machine on help.github.com didn't help.

https://cben.github.io/sandbox/README has no CNAME file, doesn't redirect.
https://cben.github.io/mathdown/ has CNAME mathdown.net file => redirects to (UPDATE: these examples no longer hold, I added/removed CNAME in these repos...)

The only current remedy seems to be removing the CNAME. (in my case it's a leftover I forgot when I moved the custom domain to heroku/openshift; in any case, it doesn't make much sense to care about https on Pages and prefer a custom domain.)

https://help.github.com/articles/custom-domain-redirects-for-github-pages-sites/ does says it redirects, but apparently talks of a weird scenario where project page redirect involves the owner's user/org page's CNAME(?) I've sent a lot of questions about that doc to github support, including whether the redirect could be suppressed when accessing github.io via https. Will report here if they answer.

dentarg commented 8 years ago

Apparently if you have a CNAME file, github now redirects all github.io to that domain, with http :-( I'm pretty sure this is new behavior?

It's not that new, I've seen it at least since beginning of October 2015. (Late October I created this related issue for Jekyll: https://github.com/jekyll/jekyll-redirect-from/issues/81)

cben commented 8 years ago

Got detailed reply; on https->http they said:

This limitation is something that is on our radar but I can't promise of or when we would implement https for custom domains or change how we manage the redirects.

dentarg commented 8 years ago

As of June 8, 2016 GitHub has finally fixed this, https://github.com/blog/2186-https-for-github-pages :-)

wchargin commented 6 years ago

GitHub has finally fixed this

Not sure if this is a regression or it was never fully fixed, but I'm still seeing this behavior for directories:

$ curl -sI 'https://wchargin.github.io/posts/managing-dependent-pull-requests' | tee >(head -n 1) >(grep -F Location:) >/dev/null
HTTP/1.1 301 Moved Permanently
Location: http://wchargin.github.io/posts/managing-dependent-pull-requests/

@mastahyeti: You authored the original post (thanks for your work on this issue so far!). Is this a known bug?

z3ntu commented 6 years ago

@wchargin Is the "Enforce HTTPS" checkbox ticked in the repository settings?

wchargin commented 6 years ago

@z3ntu Yes. (It's been on approximately since that feature was released. I just toggled it off and on and it didn't change the result of the above command.)

cben commented 6 years ago

This still happens, both on github.io with Enforce HTTPS on and custom domains with Enforce HTTPS on (the latter are a new thing, possibly still in rollout):

$ curl -IL https://spacem.github.io/dngearsim/builds/index.html HTTP/2 200 $ curl -IL https://spacem.github.io/dngearsim/builds/ HTTP/2 200 (:heavy_check_mark: no redirect given trailing slash) $ curl -IL https://spacem.github.io/dngearsim/builds HTTP/2 301 location: http://spacem.github.io/dngearsim/builds/ :negative_squared_cross_mark: HTTP/1.1 301 Moved Permanently Location: https://spacem.github.io/dngearsim/builds/ HTTP/2 200

$ curl -IL https://github-cben-sandbox.anat-beni.net/figures/index.html HTTP/2 404 (:heavy_check_mark: I don't have index.html there) $ curl -IL https://github-cben-sandbox.anat-beni.net/figures/ HTTP/2 404 (:heavy_check_mark: no redirect given trailing slash) $ curl -IL https://github-cben-sandbox.anat-beni.net/figures HTTP/2 301 location: http://github-cben-sandbox.anat-beni.net/figures/ :negative_squared_cross_mark: HTTP/1.1 301 Moved Permanently Location: https://github-cben-sandbox.anat-beni.net/figures/ HTTP/2 404

EDIT: I see same redirects to insecure http:// whether initial request is over --http2 and --http1.1.

Browsers correctly block such requests as mixed content when originated from https pages. The fix is adding the trailing slash.

dentarg commented 5 years ago

I got the following from GitHub Support yesterday about this issue

We have an issue open internally to hopefully improve this situation, but investigations have demonstrates that it is a non-trivial issue to resolve.

EDIT:

Should probably include the complete message as this issue (#289) seems to have discussed several issues with GitHub. My reply was about the issue demonstrated by @cben above.

GitHub Support wrote:

This redirection quirk that you've discovered is a known issue, and relates to trailing slashes and how our redirects work at the moment. Making a request to a URL without a trailing slash will cause redirections to run in this order:

request to original URL

301 to HTTPS version of original URL

301 to HTTP version with added trailing slash

301 to HTTPS version with added trailing slash

Always including the trailing slash will allow you to skip the extra redirects:

request to URL with trailing slash

301 to HTTPS version of original URL

We have an issue open internally to hopefully improve this situation, but investigations have demonstrates that it is a non-trivial issue to resolve.

TPS commented 5 years ago

Does anyone have any info on further progress on this?

isaacs / github