使用 HTTP 技巧重定向 GitHub Pages 站点

了解如何配置两个仓库以用作具有自定义域名的静态网站。

图片来自

Opensource.com

我在 GitHub Pages 上为我的私人项目运行了一些静态网站。我对这项服务非常满意，因为它支持自定义域名，自动重定向到 HTTPS，并透明地安装 SSL 证书（通过 Let's Encrypt 自动颁发）。它速度非常快（感谢 Fastly 的内容分发网络），而且极其可靠（多年来我没有任何问题）。考虑到我免费获得所有这些，它目前非常符合我的需求。

然而，它有一个重要的限制：因为它只提供静态网站服务，这意味着没有查询参数，没有在服务器端生成的动态内容，没有注入任何服务器端配置（例如 .htaccess）的选项，我唯一可以推送到网站根目录的是静态资源（例如，HTML、CSS、JS、JPEG 等）。一般来说，这不是一个大问题。有很多开源的静态站点生成器可用，例如 Jekyll，默认情况下可以从仪表板获得，以及我在大多数情况下更喜欢的 Pelican。然而，当您需要实现传统上在服务器端解决的某些问题时，全新的挑战就开始了。

例如，我最近不得不更改我的一个网站的自定义域名。保留旧域名非常昂贵，我不愿意继续浪费钱。我找到了一个更便宜的替代方案，并立即面临一个更大的问题：所有搜索引擎的索引中都有旧域名。更新索引需要时间，在更新完成之前，我必须将所有请求重定向到新位置。理想情况下，我会将每个索引资源重定向到新站点上的等效资源，但至少，我需要将请求重定向到新的起始页。我有足够的时间访问旧域名，因此，我可以同时在两个域名上分别运行该站点。

对于这种情况，有一个正确的解决方案，应该尽可能使用：永久重定向，或 301 Moved Permanently 状态代码，是 HTTP 协议中实现的页面重定向方式。唯一的问题是，它应该发生在服务器端，在服务器响应的 HTTP 标头中。但我可以实现的唯一解决方案位于客户端；也就是说，HTML 代码或 JavaScript。我没有考虑 JS 变体，因为我不想依赖 Web 浏览器对脚本的支持。一旦我确定了任务，我就想到了一个解决方案：HTML <meta> 标签 <meta http-equiv> 与 refresh HTTP 标头。虽然它可以用于要求浏览器在指定的秒数后重新加载页面或跳转到另一个 URL，但在一些研究之后，我了解到它比我想象的要复杂，并且有一些有趣的事实和细节。

解决方案

TL;DR（对于任何对所有细节不感兴趣的人）：简而言之，此解决方案配置两个仓库以用作具有自定义域名的静态网站。

在具有旧域名的站点上，我重建了网站的整个目录结构，并将以下 index.html（包括根目录）放在每个目录中：

<!DOCTYPE HTML>                                                                 
<html lang="en">                                                                
    <head>                                                                      
        <meta charset="utf-8">
        <meta http-equiv="refresh" content="0;url={{THE_NEW_URL}}" />       
        <link rel="canonical" href="https://open-source.net.cn/%7B%7BTHE_NEW_URL%7D%7D" />                     
    </head>                                                                                                                                                                   
    <body>                                                                      
        <h1>                                                                    
            The page been moved to <a href="https://open-source.net.cn/%7B%7BTHE_NEW_URL%7D%7D">{{THE_NEW_URL}}</a>
        </h1>                                                                   
    </body>                                                                     
</html>

当有人在旧域名上打开资源时，大多数 Web 浏览器会立即重定向到新网站上的相同资源（感谢 http-equiv="refresh"）。对于任何遗漏或不存在的资源，在旧网站的根目录中创建一个包含类似内容但没有 rel="canonical" 的 404.html 文件很有帮助（因为在这种情况下没有规范页面）。

拼图的最后一块是规范链接关系 (rel="canonical")，它可以防止内容重复，只要已实现的重定向不是永久性的。从 HTTP 响应的角度来看，当请求成功并且有迹象表明搜索引擎资源已移动并且应该与新的（首选）位置关联时，就会发生这种情况。

我了解了一些与 http-equiv="refresh" 和 rel="canonical" 相关的有趣事实。HTML 元标记 http-equiv 用于模拟服务器响应中 HTTP 标头的存在。也就是说，无法访问 Web 服务器配置的 Web 开发人员可以通过从 HTML 文档（HTTP 响应的“正文”）“注入”HTTP 标头来获得类似的结果。似乎所有流行的 Web 浏览器多年来一直使用的 refresh 标头实际上并不存在。至少不是作为标准化的 HTTP 标头。曾经有一个计划在 HTTP/1.1 规范中添加它，但该计划推迟到 HTTP/1.2（或更高版本），但从未实现。

总结

查找资源的真实源 URL 并非易事。存在不同的方案名称（HTTP、HTTPS）、多个查询参数（page.html、page.html?a=1）、解析为相同 IP 地址的各种主机名等。所有这些选项都使网页在搜索引擎看来有所不同，但页面仍然是相同的。当相同的内容发布在独立的 Web 服务上时，情况会变得更糟。2009 年，Google、Yahoo 和 Microsoft 宣布支持规范链接元素，通过允许网站管理员为同一页面的可能 URL 组选择规范（首选）URL 来清理网站上的重复 URL。这有助于搜索引擎挑选正确的 URL 以与内容关联，还可以改善网站的 SEO。

标签

GitHub