Как стать автором
Обновить

Комментарии 14

Я не очень сильно шарю в сишарпе, но насколько я могу судить, вы проверяете статус ответа HttpStatusCode.OK ( то есть 200 ).
А что будет если сервер вам ответит 301/302/403 например?
Формально — эти ссылки не битые.
HttpWebRequest имеет такое свойство как AllowAutoRedirect. Оно по умолчанию выставляется в true. Соотвественно мой запрос будет долбиться через все редиректы, пока не получит ответ от конечной страницы. (Кстати как вы могли заметить из статьи — правильная обработка редиректов в wish list'e).

Так что если в конченом итоге после 301 и 302 редиректов мы получим 200 — то все хоршо.

Что касается статуса 403 — Forbidden. То программа не сможет получить доступ к защищенному контенту и вернет мне статус Error (внутренний enum). Конечно в репорте это все отразиться и можно будет отфильтровать (если это html report) нужные нам статусы.

Кстасти спасибо за идею, добавлю в свой to-do list, чтобы программа могла проходить аутенфикацию, если того требует функционал.
У меня вопрос. Если каждая страница сайта будет выполнять на один легкий запрос к базе данных больше, благодаря чему сам сайт не будет содержать ни одной битой ссылки с себя на себя, то это целесообразно будет или нет? Имеется в виду сравнение автоматического контроля с периодической проверкой, в первом случае повышенная нагрузка все таки.
Я не уверен, что правильно Вас понял. Попробую перефразировать:
1. Проверка всех ссылок на сайте путем запуска вот такого вот консольного приложения с периодичностью день | неделя | месяц…
2. На самом сайте делать проверку и писать в лог, если она неудачна при попытке доступа на страницу сайте

Правильно? Вы просите сравнить эти 2 подхода? Я думаю у второго подхода минусов очень много:
— Не всегда есть возможность обработать все ссылки (например IIS тогда нужно перенастраивать чтобы любой контент обрабатывал сайт, а это не хорошо для статитики, напр. картинки)
— Идея в том, чтобы проверять ссылки на другие сайты, которые находятся на страницах нашего сайта, но такие ссылки не добавлять в очередь урлов для парсинга. В вашем случае это надо будет делать отдельно
— Для не очень посещаемого сайта можно проводить такие проверки раз в месяц и настроить время, когда трафик на сайт минимален, во втором случае это неоправданая нагрузка на сервер

я думаю можно еще продолжить… если придет в голову, допишу
Нет, Вы меня не правильно поняли. Я подразумеваю только ссылки с моего сайта на мой сайт. То есть если урл страницы изменился или был удален, то все ссылки на сайте ведущие на битый адрес перестанут быть ссылками и станут текстом. Это можно делать, если каждая генерируемая сервером страница будет делать на один sql запрос больше. Вот именно это того стоит?

А индексируемые ссылки на внешние ресурсы я никогда не позволял. Нет смысла спамить — нет смысла в каптче.
В голове сразу такой пример:

А свежую версию программы можете скачать здесь.

«Здесь» была сслыка на программу, но программу по этой ссылке удалили, тогда информативность этого предложения 0. Я бы даже сказал -1, так как вводит пользователя в заблуждение. Мое мнение оно того не стоит — больше вреда, чем пользы. А польза лишь в 1 случае, когда название ссылки имеет смысл в контексте контента (например статьи из википедии). На мой взгляд лучше сделать кастомный обработчик 404 статуса и как только пользователь попадает на эту страницу писать код реагирования (лог, письмо админу, заносить ошибку в БД, и т. д.)
а чем не устраивает Xenu's Link Sleuth
Изначально задача была автоматизировать такую проверку, поэтому мне нужно было запускать программу через TaskSheduler. Вот выдержка из Future List этой программы:

Command-line parameters (actually, this has already been done, for a client who agreed to pay my development time to two people I support. If you need something similar, e-mail me, the price is a $300 donation to be sent to a person I support)
если не секрет — какая причина автоматизировать, когда можно запустить, проверить, исправить и забыть
CMS сайт обновляется не девелоперами, поэтому проверки хотя бы раз в месяц нужны, вручную можно забыть их делать.
А вот это уже интересно, спасибо за линк. Нашел бы его раньше, может бы и не изобретал бы свой велосипед
Кстати, а если один из линков будет на например iso-шник, который будет весить 4 гига — вы его весь выкачаете или нет?
спасибо за замечание, надо добавить проверку при скачивании контента…

1 из вариантов это вместо GET использовать HEAD и если это не файл или картинка, то делать еще 1 запрос, но уже GET… Но в таком случае мы каждую ссылку будем запрашивать 2 раза, что не есть хорошо…
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории