为什么某些Tumblr页面上的图像无法加载,但在它们上使用wget可以正常工作?


8

因为“某些页面无法加载”而帮助朋友建立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的示例中,直接链接都指向同一图像。不过,通常,图片发布中使用的图片(与可缩放图片页面相比)使用图片的较小版本以适合页面的主题。该示例使用为较大的屏幕制作的主题,因此不需要较小的版本。

我是否已正确阅读5,表明其他人无法查看有问题的人重新发布的图像?
保罗

我发布了一个答案,但是如果您可以提供似乎破裂的博客文章的实际URL以及似乎有问题的图像的URL,那可能会有所帮助。如果可能的话,请务必编辑您的问题以添加这些详细信息。
JakeGould 2015年

@Paul我的意思是,如果我查看tumblrUser1的图像帖子未在浏览器上加载,并且如果tumblrUser2,tumblrUser3 ... tumblrUserN重新发布了tumblrUser1的帖子,浏览器也将无法在其他用户的页面上加载。
maki57年

您显示的示例都是PNG图片。您朋友的操作系统是什么?请编辑问题以澄清这一点。这可能是连接到PNG图像的核心操作系统问题。
JakeGould 2015年

@Paul我的意思是,如果我查看tumblrUser1的图像帖子,但该图像帖子未在当前浏览器中加载,并且如果tumblrUser2,tumblrUser3 ... tumblrUserN重新发布了tumblrUser1的帖子,则浏览器也将无法在其他用户上加载图像的页面。
maki57 2015年

Answers:


10

更新:图像未加载的核心问题似乎是由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

但这不是我刚才看到的。这是我进行的一系列访问的DateX-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

而这两个图片网址确实确实失败了。但是从我的角度来看,从美国纽约布鲁克林的博客文章的原始代码看,我看不到这些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而不是将图像嵌入到另一个页面中时获得图像。


1
它们是Tumblr托管的Tumblr图片帖子。我将编辑说明。
maki57年

我可能会误会,但我认为Tumblr使用了EdgeCast。无论哪种方式,感谢您的非常有趣的解释。考虑到我添加到问题中的更新时,这仍然适用吗?
maki57 2015年

1
@ maki57似乎Tumblr使用Amazon CloudFront,EdgeCast和Highwinds从其站点提供CDN内容。从我在纽约布鲁克林的优势出发,我无法重现此错误;这些Edgecast网址对我来说失败了,但是您链接到的页面给了我Highwinds CDN。我的答案中有更多详细信息,但这是Tumblr需要解决的服务器端问题。现在将投票关闭这个问题,因为实际上这不是您可以从桌面上解决的(这是该网站的目的)。
JakeGould 2015年

1
无论如何,您仍然可以回答我的主要问题“为什么”,因此,我仍然非常感谢您。我会尽快向Tumblr报告。同时,我只告诉我的朋友暂时使用wget
maki57 2015年

1
@ maki57好吧,看看HTTPS Everywhere的功能以及特定Tumblr的规则集,似乎该插件可能凸显了Tumblr处理HTTPS方式的缺陷。该插件强制使用HTTPS,而您遇到的URL似乎是“ HTTPS Everywhere”强制所有资产使用的URL。这是基于怎样的tumblr 可能工作,但它也有可能是的tumblr没有正确同步他们的EdgeCast HTTPS服务器?我也将让“ HTTPS Everywhere”的开发人员。
JakeGould 2015年

5

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

但是,如果发现问题仅对我来说是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,该URL不起作用:

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

我不确定这是否算作Tumblr方面的错误。我猜想,如果客户端不应该使用HTTPS访问其媒体服务器,那么您就不能为此真正怪罪他们。

编辑:实际上,这个GitHub线程中报告的问题似乎已经得到解决。


1

我在移动运营商T-Mobile上注意到了这种行为。我认为这是基于图像大小的某种流量调整,或者是某种载体在撤消上述物品时建立的“难度指标”。

在一年多以前的先前测试中,我然后将折断的帖子分享给了一位拥有Verizon的朋友,并且图像可以很好地加载。

虽然无法测试我将要提供的图像(由于我的朋友不可用),但该图像不会为我加载。我正在使用Chrome作为浏览器的Nexus 5上运行普通Android(5.0.1)。

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

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

编辑:这是@JakeGould发布实际图像以供参考。

在此处输入图片说明

进一步的测试和详细信息:我在巴尔的摩MD,使用LTE数据运行,以下图像确实起作用:http: //40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

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

最后的注意事项:我回到家了,跳了我的wifi -Comcast-和我的手机-我一直在测试的设备-以及由于现在可以看到504而无法看到的所有照片。

编辑:超级用户的新手,修剪和编辑的帖子,所以它更加真实,讨论更少。

更新:问题似乎与LTE有关。加载了tumblr,发现了一些无法加载的图片,将我的手机降为3g,重新加载了页面,所有图片均显示出来。将手机恢复为LTE,清除缓存,现在可以加载以前未在LTE下加载的图像。
(我正在再次测试,现在我无法复制。因此,上述行为也许是fl幸。)


这是很好的信息,但是如果您可以提供一些有关实际位置的详细信息,那么也可能会有所帮助。我可以在美国纽约布鲁克林看到与该图像相关的链接。从我的角度来看,图像是由Highwinds CDN交付的。
JakeGould 2015年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.