Какие технические функции я могу включить на свою страницу обработки ошибок 404 File Not Found?

У меня есть пользовательская страница обработки ошибок 404

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

У нас есть одна конкретная папка с изображениями, но мы получаем запросы изображений с неверными путями. Там, где мы можем найти подходящее имя изображения в /IMAGES/, мы возвращаем его. Должен ли я использовать 301? (в настоящее время мы возвращаем 200)

Мы выделяем их в отчете администратора, потому что есть вероятность, что есть ошибка в CMS или массовой электронной почте или что-то в этом роде, и, перенаправляя, мы просто маскируем проблему (и я думаю, что ее исправление повысит производительность?)

Мне интересно, должны ли мы возвращать фиктивное изображение, когда мы получаем 404 на отсутствующем JPG/GIF/PNG? В настоящее время мы возвращаем результат 404 и страницу с извинениями в HTML - что кажется мне немного глупым, сделает ли браузер пользователя что-нибудь полезное с возвращенным изображением, если есть код ответа 404?

Мне также интересно, будет ли полезно вернуть изображение «Изображение не найдено, посетите www.example.com» (возможно, в частности, если мой домен НЕ является реферером!). Тогда бесполезный человек, который встраивает наши изображения на свой сайт, причем ошибочно!, может, по крайней мере, привлечь к нам трафик.

Точно так же я должен вернуть что-то полезное, если я получу запрос 404 для файлов JS или CSS? Я думаю, в DEV, по крайней мере, было бы удобно знать, что мы облажались. Иногда отсутствующий файл может быть настолько непонятным при его использовании, что его отсутствие не учитывается при проверке качества. (Я полагаю, что кто-то ДОЛЖЕН заметить это в журналах 404!), но я думаю, может быть, установить для BODY что-то массивное или ALERT в возвращаемом файле .JS, может помочь в DEV.

Погуглив сегодня по этому поводу, я также наткнулся на предположение, что некорректно сформированная строка запроса может возвращать «400 Bad Request» и правильно сформированную строку запроса, но если параметр имеет недопустимое значение (например, код продукта не найден), его можно рассматривать как a 404. Если я сделаю это, а также верну контент (например, страницу с пояснениями), увидит ли это пользователь, или его браузер может заменить его готовой страницей с ошибкой 404? (У меня было ощущение, что это было сделано в более ранней версии IE?)

Все идеи оценены.

(Классический ASP/IIS в моем случае, но, надеюсь, вопрос общий)

Редактировать: мне также интересно, делает ли кто-нибудь что-нибудь особенное с вещами, которые выглядят как известные попытки взлома?

  • http://www.example.com:80/admin/phpmyadmin/scripts/setup.php
  • http://www.example.com:80/admin/pma/scripts/setup.php
  • http://www.example.com:80/admin/scripts/setup.php
  • http://www.example.com:80/db/scripts/setup.php
  • http://www.example.com:80/dbadmin/scripts/setup.php
  • http://www.example.com:80/myadmin/scripts/setup.php
  • http://www.example.com:80/mysql/scripts/setup.php
  • http://www.example.com:80/mysqladmin/scripts/setup.php
  • http://www.example.com:80/phpadmin/scripts/setup.php
  • http://www.example.com:80/phpMyAdmin/scripts/setup.php
  • http://www.example.com:80/phpmyadmin1/scripts/setup.php
  • http://www.example.com:80/phpmyadmin2/scripts/setup.php
  • http://www.example.com:80/pma/scripts/setup.php
  • http://www.example.com:80/web/scripts/setup.php

и эти "щупальцы":

  • http://www.example.com:80/_vti_bin/owssvr.dll?...
  • http://www.example.com:80/MSOffice/cltreq.asp?...

Edit2: Извините, надеюсь, последнее.

Должен ли я выделять идентификатор сеанса? Это позволило бы мне отслеживать, возвращается ли пользователь с чем-то более интеллектуальным при второй попытке (что может привести к добавлению записи в нашу таблицу перенаправлений). Создание сеанса включает в себя создание записи сеанса в базе данных и некоторые другие вещи, поэтому это не так «дешево», как просто выдать ошибку 404.


error-handling http-status-code-404
person Kristen    schedule 09.10.2009    source источник
comment
Дружеский совет: сократите текст вопроса или разделите его на несколько независимых вопросов. Это слишком много, чтобы всосать сразу.   -  person csl    schedule 09.10.2009

Ответы (1)


arrow_upward
0
arrow_downward

Однажды я сделал веб-страницу, которая динамически генерировала изображения. Проблема заключалась в том, как распространять ошибки, когда изображение не может быть отрисовано.

Решение, которое я считаю неплохим, состояло в том, чтобы просто напечатать сообщение об ошибке в самом изображении. Затем вы могли бы HREF изображение, и если бы это не сработало, вы бы распечатали сообщение об ошибке. Лучше, чем просто вернуть недопустимое изображение.

Для JS-файлов вы можете сделать то же самое, но я не уверен, что это будет хороший дизайн. Я не думаю, что даже возврат пустого текстового документа был бы хорошим в этом случае. Вы можете возвращать сообщения об ошибках в окнах предупреждений и подключать их к основному приложению, но я думаю, что это более полезно для разработчиков, а не для обычных пользователей. (Зависит от того, кто ваши пользователи). Я думаю, то же самое касается и CSS.

Для сообщений об ошибках в целом, если вы просто хотите знать, что был достигнут недопустимый URL-адрес, вы можете либо выполнить поиск в журналах сервера, либо вы можете скрыть скрипт за URL-адресами JS/CSS, который где-то регистрирует информативное сообщение.

Наконец, помните, что HTTP-коды создаются не просто так. Вы можете ожидать, что клиенты будут обрабатывать действительные коды ошибок HTTP лучше, чем «поддельные» и, казалось бы, хороший вывод (с точки зрения HTTP). Другими словами, вы можете использовать это в своих интересах и отвечать более конкретными кодами ошибок HTTP в ситуациях, когда обычные коды не подходят.

person csl    schedule 09.10.2009