【问题标题】:Cloudfront is redirecting to our websiteCloudfront 正在重定向到我们的网站
【发布时间】:2017-01-10 22:05:57
【问题描述】:

截至今天早上,经过多年的正常工作,我们的云端帐户已重定向 (301) 到我们的网站以获取资产,而不是自行提供资产。任何想法如何恢复这个?

昨晚我将我们从使用Passenger 改为使用Puma 作为我们的Web 服务器,作为其中的一部分,我在production.rb 中更改了config.serve_static_files = true。但是,即使我恢复到config.serve_static_files = false,云端网址仍然会重定向到我们的主页。

任何想法如何解决这个问题?

【问题讨论】:

  • 我相信 cloudfront 只会在其对源的请求也导致重定向时才会发出重定向 - 我会首先在运行 puma 的服务器上可用的任何日志中查找这些请求.
  • @FrederickCheung 您能否澄清“如果它对来源的请求也导致重定向”的意思?您是说我们运行 puma 的服务器以某种方式将云端请求重定向到自身?我应该在我们的大型日志文件中寻找什么特定的东西吗?
  • 当浏览器向云端发出请求时,云端会从您的服务器请求相关资产。听起来该请求导致重定向而不是资产。我会查看任何导致重定向的资产请求。

标签: ruby-on-rails heroku cdn amazon-cloudfront puma


【解决方案1】:

经过一番调查,问题的原因如下:

  1. Nginx 显然从 http 提供 public/ 文件,即使存在从 http 到 https 的 301 重定向
  2. Puma 使用 rack 来提供 public/ 文件,如果从 http 请求公共文件,它将返回 301 重定向到 https
  3. 如果 Cloudfront 从它路由到的服务器(在这种情况下为 http)接收到 301 重定向,它只会将 301 重定向转发给用户,因此他们将永久重定向到网站的 https,而不是到 cloudfront 来接收他们的文件。
  4. 解决此问题的配置设置将我们的云端源更改为“匹配查看器”,而不是原来的“仅 Http”。然后我们不得不等待人们的缓存被清除,因为它是一个永久重定向 (301)。

附带说明,我认为 Cloudfront 不应将 301 重定向转发给客户端。这对我来说似乎并不理想。

【讨论】:

    猜你喜欢
    • 2020-09-21
    • 1970-01-01
    • 2023-03-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-10-27
    • 1970-01-01
    • 2014-10-01
    相关资源
    最近更新 更多