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

Question

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

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

У нас есть одна специальная папка Images, но мы получаем запросы изображений с неверно сформированными путями. Где мы можем найти подходящее имя изображения в / 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.

В Googling вокруг этого сегодня я также упал на мысль, что неверно сформированная строка запроса может вернуть «400 неверных запросов» и правильно сформированную строку запроса, но где параметр имеет недопустимое значение (например, код продукта не найден) может будет восприниматься как 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

Answer 1

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

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

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

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

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