web-dev-qa-db-ja.com

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

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

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

これが発生する理由は何でしょうか？本当に私を引き付ける部分は、wgetが機能するという事実です。そのため、ネットワーク接続の問題ではないと私は思います。

更新：

ここ は、ブラウザーでのロードに失敗したレコードされた投稿の例です。 メインブログ には、適切に読み込まれる他の画像投稿があります。 This は投稿内の画像への直接リンクであり、 here はより大きなバージョンのリンクです（どちらもここに読み込まないでください）。 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の例では、両方の直接リンクが同じ画像を指しています。ただし、通常、画像投稿で使用されるもの（ズーム​​可能な画像ページと比較して）は、ページのテーマに合うように画像の小さいバージョンを使用します。この例では、大きな画面用に作成されたテーマを使用しているため、小さなバージョンは必要ありません。
google-chromefirefoxwgetchromium
8
maki57

UPDATE：ロードされない画像のコア問題は、 EFFのHTTPS Everywhereプラグイン/拡張機能 がいくつかのTumblr URLを処理する方法。開発者に通知され、 修正が行われているようです 。この回答は基本的に、最初の質問で概説されているように、問題を明らかにするために行われた検出作業を分解し、同様の問題が将来発生した場合のさらなるデバッグ/診断に役立つ可能性があります。

EDIT：画像リーチングに関する大きなコンテンツは無効のようです。したがって、誰かに役立つ場合に備えて、新しいアイデアを上部に追加し、画像のリーチング情報を下部に残します。

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であるため、ある場所のファイルにアクセスしている人は問題に気付かないかもしれませんが、別の場所にいる他の人は画像の表示に問題があります。

つまり、クライアント側で簡単に解決できるとは思いません。

EDIT：したがって、元の投稿者がいくつかの新しい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）を見ているのかということです。しかし、41.media.tumblr.comへのtracerouteを実行すると、それが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を介して画像を取得できますが、別のページに埋め込まれている場合は取得できません。

10
JakeGould

私は現在この非常に問題を抱えています。これは仕事にとって安全です。まあ、ばかげた話です 影響を受けるブログの例 。

ただし、問題がChromeでのみ発生したことが判明した場合。しばらくすると、問題の原因が拡張子「 HTTPS Everywhere 。」を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を使用してメディアサーバーにアクセスすることを想定されていない場合、実際にクライアントのせいにすることはできないと思います。

EDIT：そして、実際にはこのGitHubスレッドで報告されているように、問題は で処理されたようです 。

5
jdehesa

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

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

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

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

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

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

enter image description here

詳細なテストと詳細：私はボルチモアMDにいます。LTEデータを実行し、次の画像が機能しました： http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e /tumblr_njnalkSD7M1s5cyzso1_500.jpg

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

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

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

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

1
userWCB