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