我正在尝试确定是否有一种方法可以检查可能很大的 url 列表 (> 1000000) 的可用性，而无需向每一个发送 GET 请求。
如果http://www.example.com 无法访问（如无法连接到服务器或域的 DNS 请求失败），或者我收到 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 请求吗？
【问题讨论】：
除了其他人所说的，使用HEAD 请求而不是 GET 请求。它们的功能相同，但响应不包含消息正文，因此您可以为每个人节省一些带宽。
【讨论】：
首先不要假设任何基于单个页面失败的事情。我见过很多情况，IIS 将继续提供静态内容，但不能提供任何动态内容。
您必须将每个主机名视为唯一的，您不能假设 subdomain.example.com 和 example.com 指向同一个 IP。或者即使他们这样做，也没有同一个站点的保证。 IIS 再次具有允许您使用单个 IP 地址运行多个站点的主机标头。
【讨论】：
主机（例如 www.example.com）的 DNS 查找失败应该足以使该主机的所有 URL 无效。不过，子域或其他主机必须单独检查。
4xx 代码可能会告诉您某个特定页面不可用，但您无法据此对其他页面做出任何假设。
5xx 代码真的不会告诉您任何信息。例如，可能是页面在那里，但服务器目前太忙了。如果您稍后再试一次，它可能会正常工作。
【讨论】：
如果与服务器的连接确实失败，则没有理由检查该服务器上的 URL。否则，你不能假设任何事情。
【讨论】：
您应该对 URL 的可用性做出的唯一假设是“获取 URL 可能并且将会失败”。
假设父域请求失败时子域请求会失败是不安全的。也就是说，因为在您的两个请求之间，您的网络连接可能会上升、下降或通常行为不端。也可以在请求之间更改域。
忽略所有互联网连接问题。您仍在处理一个可以并且将不断变化的实时网站。当他们决定改变他们的页面结构或改变显示特定页面的方式时，现在的情况可能在 5 分钟内就不是真的了。你最好的选择是假设任何获取都会失败。
这似乎是一个极端的观点。但这些事件将发生。你如何处理它们将决定你的程序的健壮性。
【讨论】：
很遗憾，您无法从 4xx 或 5xx 或任何其他代码中推断出任何内容。
这些代码是针对单个页面的，而不是针对服务器的。很可能一个页面关闭而另一个页面打开，或者一个有 500 服务器端错误而另一个没有。
您可以使用HEAD 而不是GET。这会检索页面的 MIME 标头，但不会检索页面内容。这节省了服务器端时间（因为它不必渲染页面）和您自己（因为您不必缓冲然后丢弃内容）。
另外我建议您使用keep-alive 来加速来自同一服务器的响应。许多 HTTP 客户端库都会为您执行此操作。
【讨论】：