一部のTumblrページの画像が読み込まれないのに、wgetを使用すると機能するのはなぜですか？

「一部のページが読み込まれない」ため、インターネット接続で友達を助けたところ、特定のブログの画像投稿の画像がブラウザーに読み込まれなかったことが問題であることに気付きました。次の理由により、私は奇妙なことに気づきました。

1. 投稿の一部である画像のみが読み込まれません。ユーザーのアバター、バナー、ヘッダー、さまざまなテーマ、ページ関連の画像が引き続き表示されます。
2. コンピューター上の任意のブラウザーで発生します（FirefoxとChrome / iumでテスト済み）。
3. wget画像の直接リンクでの使用は機能します。
4. これはすべてのTumblrページに適用されるわけではありません。ほとんどは適切に読み込まれますが、画像を読み込まない投稿のあるページのリストを作成すると、それらがほとんど同じユーザーグループからのものであることが示されます。
5. 問題は、特定のブログの画像投稿がブラウザーに読み込まれない場合、同じ投稿を含む他のブログ（影響を受けていないかどうかにかかわらず）もブラウザーに画像を読み込まないという意味で、ブログ固有の問題のようです。逆に、影響を受けるブログが影響を受けていないブログのブログである場合、画像は正常に読み込まれます。
6. 画像は、ユーザーが作成したTumblr投稿からのもので、ユーザーが投稿する画像をアップロードし、Tumblrによってホストされます。たとえば（この例は影響を受けるブログの1つではありません）、この画像投稿（ランダムに選択）では、これは投稿内の画像への直接リンクになります。画像投稿は、ユーザーが投稿用にアップロードしたもののサイズに近い、投稿で使用される画像の（通常）より大きなバージョンを使用して、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の例では、両方の直接リンクが同じ画像を指しています。ただし、通常、画像投稿で使用されるもの（ズーム​​可能な画像ページと比較して）は、ページのテーマに合うように画像の小さいバージョンを使用します。この例では大きな画面用に作成されたテーマを使用しているため、小さなバージョンは必要ありません。}

更新：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、実際のファイルの作成/変更日と相関します。エンドポイントが持っています。

最初の4つのアクセスが数秒間隔であり、日付/時刻が異なり、それらすべてがであることに気付きました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

そして、これら2つの画像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）を見ているのかということです。しかし、次にtracerouteを実行すると、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ブログに配置されているが実際には別のホストでホストされている画像であると信じられます地点。

標準の画像リーチング手順が導入されている場合、リーチングをブロックする、別のサイトでホストされている1つのサイトで埋め込み画像を表示すると、画像リンクが壊れるか、「リーチングを停止します！」返される画像。これは、そのページの例のような基本的なリーチング防止ルールが画像リファラーをクロスチェックして、画像をリクエストしているページが画像をホストしているドメインと一致することを確認するためです。

したがってwget、画像に直接アクセスするのは、画像に直接アクセスする場合です。したがって、画像リーチングルールは適用されません。したがってwget、別のページに埋め込まれている場合は、画像を取得できますが、取得することはできません。

私は現在この非常に問題を抱えています。これは影響を受けたブログの例であり、安全です。

ただし、問題が発生したのは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スレッドで報告されているように、問題は処理されたようです。

私の携帯電話会社であるT-Mobileを使用しているときに、この動作にさらに気づきました。これは、画像サイズに基づいたトラフィックシェーピングのようなものか、上記のアイテムを取得する際にキャリアが作成した「難易度の指標」であると考えています。

1年以上前の以前のテストで、壊れた投稿をVerizonを持っている友人に共有しました。画像は正常に読み込まれます。

私が提供しようとしているこの画像をテストすることはできませんが（私の友人が利用できないため）、この画像は読み込まれません。Chromeをブラウザとして使用して、Nexus 5で標準のAndroid（5.0.1）を実行しています。

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

イメージを直接ロードしようとすると、504ゲートウェイタイムアウトエラーが発生します。

編集：これは、参照用に実際の画像を投稿する@JakeGouldです。

詳細なテストと詳細：私はボルチモアメリーランド州にいて、LTEデータを使い果たしており、次の画像は機能しました。

さらにテストを行ったところ、PNGは問題ではないようです。私がヒットした他のほとんどの画像はpngとjpgの混合でしたが、すべて "41"以外のサーバー上にありました。

最後のメモ：私は家に帰り、私のwifi -Comcast-を私の電話-私がテストしているデバイス-と504のために見ることができなかったすべての写真が今見ることができたのでホップしました。

編集：スーパーユーザーにとって新しい、トリミングおよび編集された投稿なので、より事実に基づいており、議論は少なくなりました。

更新：問題はLTEに関係しているようです。tumblrをロードし、ロードできない画像をいくつか見つけ、携帯電話を3gに強制ダウンし、ページを再ロードしました。すべての画像が表示されます。スマートフォンをLTEに戻し、キャッシュをクリアすると、以前はLTEで読み込まれなかった画像が読み込まれます。
（私はもう一度テストしていますが、今は再現できません。したがって、おそらく上記の動作はまちがっていたでしょう。）