Pull to refresh

Comments 17

Считаю, что для офлайна это все же малополезно.
А вот в онлайне можно выделять не только дохлые ссылки, но и разделять внутренние-внешние.
Кстати, все это уже реализовано, но только в рамках wiki-движков: там ссылки на несуществующие статьи отличаются от «живых».
Помнится, когда ИЕ в автономном режиме, если ссылки сохранены в кеше, то курсор при наведении на эти ссылки становится рукой. Иначе, вроде рука и значок запрета (перечеркнутый кружок)
Скрипт для Greasemonkey, ассоциированный с локальными файлами, и вперёд! :) В Опере тоже пользовательские скрипты есть.
Отличать внутренние от внешних больших проблем не составляет, что серверным скриптом, что клиентским выделить относительный адрес или адрес текущего ресурса и отметить его отдельным классом довольно просто и даже совсем почти не ресурсоёмко.

А вот проверять на дохлость ссылку сложнее, иначе как «постучаться и проверить» вариантов я не вижу, это значит при генерации страницы нам надо дожидаться пока браузер простучит все ссылки. Это дополнительный трафик, лишние запросы практически в никуда, а если ресурс на который мы долбимся висит на дохлом канале…

Кроме того, как отличить страницу 404, которую выдаёт движок, от страницы с правильным контентом без его анализа?..

> Кроме того, как отличить страницу 404, которую выдаёт движок, от страницы с правильным контентом без его анализа?

По названию?
ключевые слова «без анализа»
кроме того поиск символов «404» в загаловке страницы зачастую ничего не даст
сейчас вполне себе нормальными считаются такие вещи как «Извините, страница потерялась» «Возможно вы ошиблись» или даже «ой 0_0»
не, я имел в виду по названию файла, который отдает сервер. Мне казалость что имя стандартное: «404.shtml», нет?
движком чаще всего отдается тот же index.php с параметрами
404, которая выдаётся движком, всё равно имеет код 404.
А если нет — думаю, такому движку место на помойке.
что вы имеете ввиду под кодом? если движок не нашел в базе страницу по запросу, он всё равно выдает index.php со стандартным сообщением и какие у него тайтлы, текст и всё остальное настраивает человек.

в любом случае бОльшая проблема всё равно не в этом, а в запросах по всем ссылкам со страницы источника
Я имею ввиду код HTTP-ответа. Ничего не мешает сделать его красивым для пользователя и генерировать с помощью вышеуказанного index.php, ну или views.py, в зависимости от того, что больше нравится.

А про запросы по всем ссылкам — да, беда. Но не надо же при каждом запросе их проверять — а раз в неделю-месяц «проиндексировать» контент можно.
ах вот что вы имеете ввиду, про http ответы я совсем мало знаю, поэтому и не учёл такой в общем то очевидной вещи… да…

проиндексировать можно, это приемлемый вариант, но в нем мне видится целая куча подводных камней, хотя тут надо конкретные ситуации рассматривать пожалуй…
в онлайне, скорее всего, лучше проверять ссылки на стороне сервера:
Периодически запускать какую-нибудь проверялку на уровне веб-сервера, складывать куда-то полученные данные и уже при запросе документа серверным скриптом это дело зачитывать и соответственно реагировать.
ну это единственный приемлемый вариант, да…
Only those users with full accounts are able to leave comments. Log in, please.