了解服务器/客户端路由：亚马逊（？）如何在没有重定向（或历史条目）的情况下重定向我的 SPA？

Posted 2023-03-27

【中文标题】了解服务器/客户端路由：亚马逊（？）如何在没有重定向（或历史条目）的情况下重定向我的 SPA？

【英文标题】：Understanding Server/Client Routing: How Can Amazon(?) Be Redirecting My SPA ... Without a Redirect (or History Entry)?

【发布时间】：2021-01-25 17:03:09

【问题描述】：

注意：我提供的是设置的详细信息，但实际上这是一个“这怎么可能”的问题，而不是“请调试我的设置”的问题。

我有一个“单页应用程序”（即一个使用 History API 来模拟 URL 的 html 文件）。我在 AWS Cloudfront ... 前端后面的 AWS S3 上提供此应用程序。

我已经成功配置了一些东西，所以如果有人访问www.example.com/foo（假设我拥有example.com），Cloudfront 将提供我的index.html 的“错误页面”。然后我的index.html 会看到 URL，并使用它的路由向用户显示正确的页面。

这一切都很好......直到它没有。现在由于某种原因，当我转到www.example.com/foo 时，我被重定向到www.example.com。我正在尝试调试东西，但我不明白我是如何从/foo 转到主页的。

当我查看我的开发人员工具的网络面板时，我可以看到对原始 (/foo) 的请求。然后我可以看到请求链（对于图像、css 文件等），它们都有一个 www.example.com/foo 的引用者。

然后突然间我看到了一个对 React Developer 工具的请求（为什么它需要发出请求超出了我的范围）......它来自推荐人 www.example.com。之后我收到了来自/foo 的最后一个图像请求，然后所有后续请求都来自www.example.com。

谁能解释一下这是如何工作的？我知道，如果服务器返回可能会更改我的 URL 的重定向（任何一种类型）......但每个请求都有 200 状态（即没有服务器重定向）。

我知道 javascript 可以“推送”一个新 URL 到我的浏览器……但这会留下一个历史条目，对吗？当我“返回”（使用我的浏览器或history.back()）时，我会转到之前的页面；我不会“返回”/foo。

所以不知何故，我没有创建历史条目，但我正在切换我的 URL，以及我从中发出请求的 URL，这一切都发生在页面加载的几毫秒内......没有任何重定向。怎么样？

附：当我使用我的开发工具添加一个beforeunload 断点，然后尝试从example.com 导航到example.com/foo 我不打到那个断点（要么去/foo，或者当我被“重定向”回example.com)。

当我选中 any 加载事件的复选框时，我确实看到了一些事情发生……在我的 URL 已经切换。换句话说，我输入example.com/foo，按回车键，当任何事件触发时，我又回到example.com。无论机制在这里执行“重定向”...它都不会触发 任何 加载事件。

【问题讨论】：

只是一个疯狂的猜测：你能检查一下你是否部署了应用程序的开发版本吗？

我正在使用带有插件的 Gatsby 来部署到 S3，所以我只能可以部署构建的应用程序.. 我想。我确实看到了对webpack-runtime-3df70ac39eb3b89a09b7.js 的请求，但我很确定这只是 Webpack 生成的构建文件，而不是一些开发工件。

P.S.即使我确实部署了开发版本......我仍然试图了解 如何（即技术机制）开发版本可能会导致我所描述的行为。具体来说，URL 在加载期间发生变化，没有重定向响应，也没有来自客户端重定向的历史条目。

【参考方案1】：

感谢一些 Gatsby 文档，我发现了我的（AWS 特有的）问题。我将在下面提供详细信息以防对其他人有所帮助，但我不会接受这个答案，因为我仍然不明白 AWS 是如何做到的（我仍然欢迎对此的回答）。

发生的事情是我的 Cloudfront“源域名和路径”指向：

example.com.s3.amazonaws.com

但是，正如 https://www.gatsbyjs.com/docs/deploying-to-s3-cloudfront/ 中所述：

您可以通过两种方式将 CloudFront 连接到 S3 源。 AWS 控制台建议的最明显方法是在 Origin Domain Name 字段中键入存储桶名称。这将设置 S3 源，并允许您将 CloudFront 配置为使用 IAM 访问您的存储桶。不幸的是，这也使得无法执行服务器端 (301/302) 重定向，这也意味着目录索引（当有人试图访问目录时提供 index.html）将仅在根目录中有效。您最初可能不会注意到这些问题，因为 Gatsby 的客户端 JavaScript 弥补了后者，而诸如 gatsby-plugin-meta-redirect 之类的插件可以弥补前者。但仅仅因为你看不到这些问题，并不意味着它们不会影响搜索引擎。

为了使您网站的所有功能都能正常工作，您必须改为使用 S3 存储桶的静态网站托管终端节点作为 CloudFront 源。这确实（很遗憾）意味着您的存储桶必须配置为公开读取，因为当 CloudFront 使用 S3 静态网站托管端点地址作为源时，它无法通过 IAM 进行身份验证。

一旦我将 Cloudfront“源域名和路径”更改为存储桶的静态托管 URL：

http://example.com.s3-website-us-west-1.amazonaws.com

一切正常！

但是，当我错误地设置“源域名和路径”时，我仍然不明白 AWS 是如何做到的。它将我重定向到我的根域，似乎没有重定向响应或客户端重定向，我很想听听这是如何完成的。