☰

为什么某些 Tumblr 页面上的图片无法加载，但使用 wget 却可以加载？

tag-icon • tag-icon google-chrome firefox wget chromium
为什么某些 Tumblr 页面上的图片无法加载，但使用 wget 却可以加载？

在帮助一位朋友解决“某些页面无法加载”的网络连接问题时，我注意到问题是某些博客的图片帖子中的图片无法在浏览器上加载。我发现这很奇怪，原因如下：

  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]

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

笔记：

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

答案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 上的典型行为是第一次访问将传达“来自云端的未命中”，然后如果您随后立即进行另一次访问，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但当图像嵌入到其他页面时则无法获取图像。

答案2

我现在就遇到了这个问题。这是一部安全的漫画——好吧，这是一部愚蠢的漫画——受影响博客的示例。

我发现这个问题只发生在 Chrome 上。过了一会儿，我意识到问题的根源是扩展程序“无处不在的 HTTPS”。当我在 Firefox 中安装它时，我也遇到了同样的问题。实际上，如果我禁用 HTTPS 规则“Tumblr (partial)”（我猜是这个意思*.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 上的这个帖子所述。

答案3

我在使用我的移动运营商 T-Mobile 时更注意到了这种行为。我认为这是基于图像大小的某种流量整形，或运营商在检索上述项目时建立的“难度指标”。

在之前的测试中（一年多以前），我将损坏的帖子分享给了一位使用 Verizon 的朋友，图像加载正常。

虽然我无法测试我即将提供的图像（因为我的朋友不在），但该图像无法加载。我在 Nexus 5 上运行 Android 原生系统 (5.0.1)，使用 Chrome 作为浏览器。

http://41.media.tumblr.com/efebad51567e927b8f130f9bdc4efae3/tumblr_ndvnpjcBZa1qewacoo1_500.png

当我尝试直接加载图像时，出现 504 网关超时错误。

编辑：这是@Giacomo1968 发布的实际图像，供参考。

在此处输入图片描述

进一步的测试和详细信息：我在马里兰州巴尔的摩，运行 LTE 数据，以下图像确实有效：http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

进一步的测试表明 PNG 似乎不是问题所在。我遇到的其他大多数有效图像都是 png 和 jpg 的混合，但都在非“41”服务器上。

最后说明：我回到家，用我一直在测试的设备手机连接到我的 WiFi -Comcast - 现在我可以看到由于 504 而无法看到的所有照片了。

编辑：作为超级用户的新手，修剪和编辑了帖子，使其更具事实性，减少讨论。

更新：问题似乎与 LTE 有关。加载 tumblr 后，发现有些图片无法加载，我强制将手机降到 3g，重新加载页面，所有图片都显示出来。将手机恢复到 LTE，清除缓存，之前在 LTE 下无法加载的图片现在可以加载了。
（我再次测试，现在无法重现。所以也许上述行为只是偶然。）

相关内容