为什么某些 Tumblr 页面中的图像无法加载，但对它们使用 wget 却能正常工作？

Question

由于“某些页面无法加载”而帮助朋友解决 Internet 连接问题，我注意到问题在于某些博客图片帖子的图片未在浏览器上加载。我觉得这很奇怪，原因如下：

1. 只有属于帖子的图片不会加载。用户头像、横幅、标题、各种主题和/或页面相关图像仍会出现。
2. 发生在计算机上的任何浏览器上（在带和不带广告/脚本拦截器的 Firefox 和 Chrome/ium 上测试）。
3. 使用wget上的影像直接链接的作品。
4. 这不适用于所有 Tumblr 页面。大多数都可以正确加载，但是当列出不加载图像的帖子的页面时，表明它们大多来自同一群用户。
5. 问题似乎是特定于博客的，因为如果某个博客的图片帖子未在浏览器中加载，则转发同一帖子的其他博客（不受影响或不受影响）也不会在浏览器中加载该图片。相反，如果受影响的博客是从未受影响的博客转发的，则图像加载正常。
6. 图像来自用户创建的 Tumblr 帖子，用户上传图像以发布并由 Tumblr 托管。例如（此示例不是受影响的博客之一），在此图片帖子（随机选择）中，这将是帖子中图片的直接链接。图片帖子会自动将图片链接到Tumblr 中的另一个页面，使用帖子中使用的图片的（通常）更大版本，该版本更接近用户为帖子上传的大小。

发生这种情况的原因可能是什么？真正让我感动的部分是有效的事实wget，所以我想我可以假设这不是网络连接的问题。

更新：

这是无法在浏览器上加载的转发帖子的示例。在博客主有正确加载其他图像的帖子。这是帖子中图片的直接链接，这里是更大版本的链接（两者都不在此处加载）。wget两者都适用，但是在转到与 Firefox 的任何直接链接时，会出现此错误：

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<Error>
    <Code>AccessDenied</Code>
    <Message>Access Denied</Message>
    <RequestId>A626307DF577B411</RequestId>
    <HostId>J9GxX1HY9vX3ElWjYf7M48ByvKXLRIwRBJ2al2voS3J/C+WhILWHyd3crFhhNtkXuvG0zaxBTxw=</HostId>
</Error>

RequestID并且HostId每次都在变化。我和我的朋友位于菲律宾。

更新 [2014/03/08]

在进一步测试和回复 Tumblr 支持的电子邮件后，wget在某些情况下已停止工作（在直接链接上出现 403 错误）。

更新 [2014/03/09]

关闭 HTTPS-Everywhere 的 Tumblr 规则似乎有时可以解决问题。

---

_笔记：

• _{在#6 的示例中，直接链接都指向同一个图像。但是，通常情况下，图像帖子中使用的图像（与可缩放图像页面相比）使用较小版本的图像来适应页面的主题。该示例使用为较大屏幕制作的主题，因此不需要较小的版本。}

Answer 1

更新：似乎无法加载图像的核心问题源于EFF 的 HTTPS Everywhere 插件/扩展程序处理一些 Tumblr URL 的方式。开发人员已收到通知，并且修复似乎已经到位。这个答案基本上分解了为发现最初问题所概述的问题所做的侦探工作，并且如果将来出现类似问题，可能对进一步调试/诊断有用。

编辑：关于图像窃取的较大内容似乎无效。所以会在顶部添加一个新想法，并在底部留下图像提取信息，以防万一它对某人有用。

Amazon CloudFront CDN 创意

好的，使用您提供的 URL 以及我在 Amazon CloudFront CDN 设置方面的一些实际经验，我想我发现了一些东西。由于某种原因，Tumblr 的 Amazon CloudFront CDN 配置似乎令人窒息。这就是为什么我认为情况如此。

让我们以这个 URL 为例：

http://36.media.tumblr.com/d685b02fdf2d3f167c22d9a97e27e87a/tumblr_nfpq5qPZ4v1tognpro1_1280.png

现在让我们运行curl -I以获取有关该文件的标题信息：

curl -I http://36.media.tumblr.com/d685b02fdf2d3f167c22d9a97e27e87a/tumblr_nfpq5qPZ4v1tognpro1_1280.png

输出将是这样的：

HTTP/1.1 200 OK
Content-Type: image/png
Content-Length: 782141
Connection: keep-alive
Accept-Ranges: bytes
Cache-Control: max-age=1209600
Date: Thu, 05 Mar 2015 02:15:44 GMT
Server: nginx
X-Cache: Miss from cloudfront
Via: 1.1 7e54fc06cd70e4752fe050bbe5c130be.cloudfront.net (CloudFront)
X-Amz-Cf-Id: QyIUyzfaJJN3PU_xWkW0P-D2kjg_1cVenKzFAoY2PubgZQlBHWorZQ==

现在需要注意的是Date（CloudFront 终端节点上文件的日期和时间）和X-Cache（Amazon 内容交付状态）标头。Amazon CloudFront 上的典型行为是第一次访问将传达“来自 Cloudfront 的小姐”，然后如果您之后立即执行另一个访问curl -I，则应该有一个Hit from cloudfront.

但这不是我刚才看到的。以下是我进行的一系列访问的详细信息Date和X-Cache状态：

• Date: Thu, 05 Mar 2015 02:19:37 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:39 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:44 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Hit from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Hit from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Hit from cloudfront

有多个具有相同确切数据且Hit from cloudfront接近末尾的项目的原因是因为这就是 CDN 上发生的情况：如果 CDN 的端点具有该文件，则Date与该文件的实际创建/修改日期相关端点有。

您注意到前四个访问间隔几秒钟，具有不同的日期/时间，并且它们都是Miss from cloudfront，对吗？这意味着 CDN 端点只是回应说当时有人尝试访问该文件，但所有尝试都失败了。

所以我对此的扶手椅评估是 Tumblr 的系统跟不上 Amazon CloudFront CDN 或 Amazon CloudFront CDN 跟不上 Tumblr。但在某种程度上，他们的服务器端出了问题。由于这是一个 CDN，在一个位置访问文件的人可能不会注意到问题，而另一个位置的其他人在查看图像时可能会遇到问题。

总而言之，我认为这不能在客户端轻松解决。

编辑：所以原始海报添加了一些新的 URL，这仍然指向服务器端问题，但我只想发布记录的详细信息。

EdgeCast 和 Highwinds CDN 创意

因此原始海报添加了更多细节，因此这里是基于用作示例的博客文章的更多详细信息：

http://claystorks.tumblr.com/post/112741831192/soulmister-claystorks-windspeare-explain

这些图片 URL 是作为该帖子中的 URL 示例提供的：

https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_500.png

https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_1280.png

这两个图像 URL 确实失败了。但是从我的角度来看——查看来自美国纽约布鲁克林的博客文章的原始源代码——我没有看到那些 EdgeCast ( gs1.wac.edgecastcdn.net) URL。相反，这些是我看到的 URL：

http://41.media.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_500.png

http://41.media.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_1280.png

所以我的第一个想法是为什么原始海报会看到那些 EdgeCast ( gs1.wac.edgecastcdn.net)。但是，如果我对它进行跟踪路由，41.media.tumblr.com我会看到这是一个由 Highwinds 管理的服务器（！？！？）。相比之下，原始用户传递的初始 URL 使用36.media.tumblr.com主机名，您可以看到它们由 Amazon CloudFront CDN 服务器管理。

总而言之——我之前说过——所有这些似乎都是 Tumblr 及其 CDN 管理的服务器端问题。但从我这边 - 在美国纽约布鲁克林 - 我清楚地看到内容从 Highwinds CDN 服务器和 Amazon CloudFront CDN 服务器按预期交付。这些 EdgeCast URL 来自何处或它们如何/为什么失败，这在客户端是任何人都无法控制的。这肯定是需要联系 Tumblr 技术人员的事情，因为桌面终端用户无法解决这个问题。

图像窃取想法

可能不再相关，但在这里供参考。

你说这给了我一个线索：

使用wget上的影像直接链接的作品。

许多站点都有防止图像窃取的规则——通常是通过 Apache 设置的。此处提供了有关这些规则如何工作的更多详细信息，并总结如下：

使用 .htaccess，您可以禁止在您的服务器上进行热链接，例如，那些试图链接到您网站上的图像或 CSS 文件的人会被阻止（请求失败，例如损坏的图像）或提供不同的内容（即：一个愤怒的人的形象）。

根据您的描述以及您可以通过wget以下方式访问图像的事实，我相信您遇到问题的图像不是由用户托管在 Tumblr 上的，而是放置在 Tumblr 博客上但实际上托管在另一个博客上的图像地点。

当标准的图像窃取程序到位时，在另一个站点上托管的一个站点上查看嵌入的图像（这会阻止窃取）将导致图像链接损坏或“停止窃取！” 正在返回的图像。这是因为基本的反窃取规则（例如该示例页面中的规则）交叉检查图像引用，以确保请求图像的页面与托管图像的域匹配。

因此，当您通过访问图像时，wget您是直接访问图像。因此图像窃取规则不会生效。因此，您可以通过wget但不能在嵌入另一个页面时获取图像。

Answer 2

我目前遇到了这个问题。这是一个安全的工作 - 嗯，这是一个愚蠢的漫画- 受影响博客的例子。

但是，如果发现问题只发生在 Chrome 中。过了一会儿，我意识到问题的原因是扩展名“ HTTPS Everywhere”。当我在 Firefox 中安装它时，我也遇到了同样的问题。实际上，如果我禁用 HTTPS 规则“Tumblr（部分）”（我猜是指*.tumblr.com），它又可以正常工作了。

因此，问题似乎是，至少有时，当使用 HTTPS 访问图像时，您会被重定向到无效的 EdgeCast URL。例如，这个图像 URL 工作正常：

http://36.media.tumblr.com/57d2af15f7b21037364125f9f32c4379/tumblr_nktjzyNkv91s667kio1_1280.png

但是，如果您将协议从 更改为http，https则会被重定向到这个不起作用的 URL：

https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/57d2af15f7b21037364125f9f32c4379/tumblr_nktjzyNkv91s667kio1_1280.png

我不确定这是否算作来自 Tumblr 方面的错误。我想，如果客户不应该使用 HTTPS 访问他们的媒体服务器，那么你真的不能责怪他们。

编辑：实际上这个问题似乎已经按照这个 GitHub thread 中的报告进行了处理。