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

Question

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

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

У нас есть одна конкретная папка «Изображения», но мы получаем запросы изображения с искаженными путями. Где мы можем найти соответствующее имя изображения в/IMAGES /, мы возвращаем это. Должен ли я использовать 301? (в настоящее время мы возвращаем 200)

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

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

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

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

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

(Classic ASP/IIS в моем случае, но, надеюсь, этот вопрос является общим)

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

• http://www.example.com:80/ админ/PHPMyAdmin/скрипты/Setup.php
• http://www.example.com:80/ администратора/PMA/скрипты /setup.php
• http://www.example.com:80/ админ/скрипты/setup.php
• http://www.example.com:80/ дб/скрипты/настройки .php
• http://www.example.com:80/ dbadmin/scripts/setup.PHP
• http://www.example.com:80/ MyAdmin/скрипты/setup.php
• http://www.example.com:80/ MySQL/скрипты/setup.php
• http://www.example.com:80/ mysqladmin/скрипты/setup.php
• http://www.example.com:80/ phpadmin/скрипты/setup.php
• http://www.example.com:80/ phpMyAdmin/scripts/setup.php
• http://www.example.com:80/ phpmyadmin1/скрипты/setup.php
• http://www.example.com:80/ phpmyadmin2/скрипты/setup.php
• http://www.example.com:80/ PMA/скрипты/setup.php
• http://www.example.com:80/ веб/скрипты/setup.php

и эти «щупы»:

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

Редактировать2: Извините, надеюсь, что последний после-хотя.

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

Answer 1

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

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

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

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

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