內容協商是否被破壞？

Question

我最近對網絡爬蟲感興趣，但有一點對我來說並不是很清楚。想象一下，一個簡單的抓取工具可以獲取頁面，從中提取鏈接並將其排入隊列，以便以相同的方式進行後續處理。

當某些鏈接不會導致另一個頁面，而是某些資產或其他類型的靜態文件，抓取工具如何處理這種情況？它會如何知道？它可能不想下載這種可能的大型二進制數據，甚至不需要xml或json文件。談判內容是如何落入這個的？

我怎麼看內容協商應該工作是在Web服務器上的一面，當我發出example.com/foo.png與Accept: text/html請求應該給我回一個HTML響應或Bad Request狀態，如果它不能滿足我的要求，其他什麼都可以接受的，但這不是它在現實生活中的作用。即使我告訴它，我仍然會用Content-Type: image/png發送二進制數據，我只接受text/html。爲什麼Web服務器像這樣工作，而不是強迫我要求的正確迴應？

內容協商的實施是否中斷或者應用程序有責任正確實施它？

真實抓取工具是如何工作的？提前發送HEAD請求以檢查鏈接的另一端看起來是不切實際的資源浪費。

Answer 1

不是'錯誤的請求'，正確的響應是406不可接受。

HTTP規範聲明它應該發回此規範[1]，但大多數實現不這樣做。如果你想避免下載一個你不感興趣的內容類型，你唯一的選擇就是首先做一個HEAD。 由於您可能已經抓取了這些圖片，因此您也可以進行一些智能猜測，其實是一張圖片（例如，它出現在<img>標籤中）。

您也可以正常開始請求，只要您注意到要獲取二進制數據，請儘量縮短TCP連接。但我不確定這是一個好主意。

Answer 2

爬行者必須一直在尋找壞信息：一些網站有一個名爲/robots.txt的10兆字節電影。即使內容協商實際上是在web服務器中實現的，許多web服務器都配置了不正確的內容類型，大量的文件具有錯誤的擴展名，並且合理的文件開始並不意味着它不會變成二進制文件，巨大的。