Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove CNAME to avoid HTTP hops #32
This simply prevents the HTTP-based 302 in an otherwise HTTPS only setup.
By removing the CNAME, we'll get a valid HTTPS response on this origin without the redirect.
This PR is predicated on the assumption that Fastly is set to use https://rubygems.github.io as the origin source for http[s]?://blog.rubygems.org.
I'm going to assume that the above 404 behavior was a temporary state and due to DNS/CDN caches not fully expiring yet...
Fastly was pointed to https://rubygems.github.io as origin. However, if you had a cached response from Fastly for the 302 to http://blog.rubygems.org, then you might also need to have Fastly expire the cache on the 302 or it would continue to fail because DNS cache for blog.rubygems.org still pointed at GitHub servers and because of the lack of a CNAME at that specifc time window that would explain 404s from github for a domain it no longer has a VHOST mapping for.
@indirect and I jumped on Fastly config and learned that Fastly acts a little different than CloudFront in that it preserves the original requests Host header and carries it through. Because of this we would need to add what Fastly calls an "Override host" to force the Fastly to GitHub Pages to be overridden from "blog.rubygems.org" to the true host header of the origin "rubygems.github.io" and then we could nuke the CNAME file.
All that said, we're likely just going to hang in the current state until we can jump on GitHub pages beta for HTTPS, which we expect to be able to try out soon.