Есть ли какие-либо безопасные предположения о доступности URL?

Question

Я пытаюсь определить, есть ли способ проверить наличие потенциально большого списка URL-адресов (> 1000000), не отправляя запрос GET каждому из них.

Безопасно ли предположить, что если http://www.example.com недоступен (например, при невозможности подключения к серверу или DNS-запрос домена не удается), или я получаю ответ 4XX или 5XX, то что-либо из этого домена также будет недоступен (например, http://www.example.com/some/path/to/a/resource/named/whatever.jpg)? Достаточно ли будет ответа 302 (скажем для what.jpg), чтобы опровергнуть первое предположение? Я полагаю, что поддомены следует рассматривать как http://subdomain.example.com и http://www.example.com может не направлять на тот же ip?

Кажется, я могу придумать контрпример для каждого ярлыка, который мне нужен. Должен ли я просто прикусить пулю и разослать запросы GET на каждый URL?

Answer 1

К сожалению, нет, вы не можете вывести ничего из 4xx или 5xx или любых других кодов.

Эти коды предназначены для отдельных страниц, а не для сервера. Вполне возможно, что одна страница не работает, а другая работает, или одна имеет ошибку 500 на стороне сервера, а другая нет.

Что вы можете сделать, это использовать HEAD вместо GET. Это возвращает заголовок MIME для страницы, но не содержимое страницы. Это экономит время на стороне сервера (потому что ему не нужно отображать страницу) и для себя (потому что вам не нужно буферизовать, а затем отбрасывать содержимое).

Также я предлагаю вам использовать keep-alive для ускорения ответов с того же сервера. Многие клиентские библиотеки HTTP сделают это за вас.

Answer 2

Неудачного поиска DNS для хоста (например, www.example.com) должно быть достаточно, чтобы сделать недействительными все URL для этого хоста. Субдомены или другие хосты должны проверяться отдельно.

Код 4xx может указывать на то, что конкретная страница недоступна, но вы не можете делать никаких предположений относительно других страниц.

Код 5xx действительно ничего вам не скажет. Например, может быть, страница есть, но сервер сейчас слишком занят. Если вы попробуете это позже, это может работать нормально.

Answer 3

Во-первых, не предполагайте, что что-то происходит из-за сбоя одной страницы. Я видел много случаев, когда IIS будет продолжать обслуживать статический контент, но не сможет обслуживать какой-либо динамический контент.

Вы должны рассматривать каждое имя хоста как уникальное, вы не можете предполагать, что subdomain.example.com и example.com указывают на один и тот же IP-адрес. Или даже если они это сделают, нет гарантии того же сайта. В IIS снова есть заголовки узлов, которые позволяют запускать несколько сайтов с использованием одного IP-адреса.

Answer 4

Единственное предположение о доступности URL-адреса, которое вы должны сделать, заключается в том, что «Получение URL-адреса может и не получится».

Небезопасно предполагать, что запрос субдомена не удастся выполнить, если запрос родительского. А именно потому, что в промежутке между вашими двумя запросами ваше сетевое соединение может увеличиваться, ухудшаться или вообще работать неправильно. Также возможно изменение доменов между запросами.

Игнорирование всех проблем с интернет-соединением. Вы по-прежнему имеете дело с живым веб-сайтом, который может и будет постоянно меняться. То, что верно сейчас, может быть неверным через 5 минут, когда они решат изменить структуру своей страницы или изменить способ отображения конкретной страницы. Лучше всего предположить, что любая попытка провалится.

Это может показаться крайней точкой зрения. Но эти события произойдут . От того, как вы с ними справитесь, зависит надежность вашей программы.

Answer 5

В дополнение к тому, что говорят все остальные, используйте HEAD запросы вместо запросов GET. Они функционируют одинаково, но ответ не содержит тела сообщения, поэтому вы экономите каждому пропускную способность.

Answer 6

Если подключение к серверу действительно не удается, нет необходимости проверять URL-адреса на этом сервере. В противном случае вы не можете ничего предположить.