4

最近、Web クローラーに興味を持ちましたが、よくわからないことが 1 つあります。ページを取得し、そこからリンクを抽出し、後で同様に処理するためにそれらをキューに入れる単純なクローラーを想像してみてください。

特定のリンクが別のページではなく、何らかのアセットまたは他の種類の静的ファイルにつながる場合、クローラーはどのように処理しますか? どうやって知るのでしょうか？おそらく、このような大規模なバイナリ データや、xml や json ファイルでさえもダウンロードしたくないでしょう。コンテンツ ネゴシエーションはこれにどのように分類されますか?

コンテンツ ネゴシエーションがどのように機能するかは、Web サーバー側で要求を発行したときに、要求をexample.com/foo.png満たさAccept: text/htmlない場合は html 応答または Bad Request ステータスを返す必要があります。実生活。Content-Type: image/pngとにかく、私が受け入れるだけだと言っているときでも、そのバイナリデータを送り返しますtext/html。Web サーバーがこのように動作し、要求している正しい応答を強制しないのはなぜですか?

コンテンツ ネゴシエーションの実装が壊れていますか、それとも正しく実装するのはアプリケーションの責任ですか?

そして、実際のクローラーはどのように機能するのでしょうか? リンクの反対側にあるものを確認するために HEAD リクエストを先に送信することは、非現実的なリソースの浪費と見なされます。

4

2 に答える 2

5

'Bad Request'ではなく、正しい応答は406NotAcceptableです。

HTTP仕様では、この仕様を返送する必要があると述べられています[ 1 ]が、ほとんどの実装ではこれを行いません。興味のないコンテンツタイプのダウンロードを避けたい場合は、最初にHEADを実行するしかありません。<img>おそらくこれらの画像をクロールしたので、それが実際には画像であった（たとえば、タグに表示された）ことをインテリジェントに推測できる場合もあります。

通常どおりリクエストを開始することもできます。バイナリデータが返されていることに気づいたらすぐに、TCP接続を短くします。しかし、これがどれほど良いアイデアかはわかりません。

于 2012-07-12T12:02:21.820 に答える
0

クローラーは常に悪い情報に注意する必要があります。一部のサイトには、/robots.txt という名前の 10 メガバイトのムービーがあります。コンテンツ ネゴシエーションが実際に Web サーバーに実装されていたとしても、多くの Web サーバーでは正しくないコンテンツ タイプが構成されており、多くのファイルの拡張子が間違っています。巨大です。

于 2012-07-13T22:35:37.897 に答える