我想確定是否有辦法檢查可能的大型URL列表（> 1000000）的可用性，而不必向每個URL發送GET請求。是否有任何關於URL可用性的安全假設？
是否安全地假設如果http://www.example.com無法訪問（如無法連接到服務器或域請求失敗），或者我得到4XX或5XX響應，則該域中的任何內容也將無法訪問（例如http://www.example.com/some/path/to/a/resource/named/whatever.jpg）？一個302響應（對於whatever.jpg來說）是否足以使第一個假設無效？我想像子域應該被認爲是不同的，因爲http://subdomain.example.com和http://www.example.com可能不會直接指向相同的ip？
我似乎能夠想到我提出的每個快捷方式的反例。我是否應該咬緊牙關並向每個URL發送GET請求？
不幸的是，不，你不能推斷任何從4xx或5xx或任何其他代碼。
這些代碼是針對單個頁面的，而不是針對服務器的。很可能一個頁面關閉，另一個頁面關閉，或者一個頁面有500個服務器端錯誤，另一個頁面錯誤。
你可以做的是使用HEAD而不是GET。這將檢索頁面的MIME頭，但不是頁面內容。這節省了服務器端的時間（因爲它不必渲染頁面）和自己（因爲您不必緩衝並丟棄內容）。
另外我建議你使用keep-alive來加速來自同一臺服務器的響應。許多HTTP客戶端庫將爲您執行此操作。
關於URL可用性的唯一假設是「獲取URL可能會失敗」。
假設子域請求在父域請求失敗時不安全。也就是說，因爲在兩個請求之間，您的網絡連接可能會升高，降低或通常不當。也可以在請求之間更改域。
忽略所有的互聯網連接問題。你仍然在處理一個可以並且會不斷變化的實時網站。當他們決定改變他們的頁面結構或改變顯示特定頁面的方式時，現在的情況可能不會在5分鐘內成立。你最好的選擇是假定任何獲得失敗。
這可能看起來像是一個極端的觀點。但是這些事件會發生。你如何處理它們將決定你的程序的健壯性。
如果到服務器的連接確實失敗，那麼沒有理由檢查該服務器上的URL。否則，你不能承擔任何事情。
主機（例如www.example.com）的DNS查找失敗應該足以使該主機的所有URL無效。子域或其他主機必須單獨檢查。
4xx代碼可能會告訴您某個特定的頁面不可用，但您無法對此進行其他頁面的任何假設。
5xx代碼真的不會告訴你任何東西。例如，可能是頁面在那裏，但服務器此刻正忙得不亦樂乎。如果你以後再試一次，它可能會正常工作。
首先不要假設任何基於單頁失敗的事情。我看到很多情況下IIS將繼續提供靜態內容，但無法提供任何動態內容。
您必須將每個主機名視爲唯一，您不能假定subdomain.example.com和example.com指向相同的IP。或者即使他們這樣做也沒有保證是同一個網站。 IIS再次具有主機頭，允許您使用單個IP地址運行多個站點。
除了其他人在說什麼之外，請使用HEAD請求而不是GET請求。它們的功能相同，但響應不包含消息體，因此可以爲每個人節省一些帶寬。
