использование customErrors для тщеславных URL / перенаправления URL asp.net

Question

Итак, с здесь ...

В ASP.NET у вас есть выбор, как реагировать на это - он находится в web.config как CustomErrors. Включите это, затем перенаправьте на модную страницу 404 (возможно, вы уже делаете). Таким образом, на необычной странице 404 можно было бы проверить запрошенную строку запроса (которая передается на пользовательскую страницу ошибки как еще одну строку запроса), чтобы определить, является ли она допустимым перенаправлением, существует ли оно в вашей базе данных и т. Д. Просто выполните Response.Redirect ( ) оттуда.

Тогда Шхуна пишет:

Спасибо, у нас сейчас есть 404, но мы бы предпочли, чтобы это не было обнаружено как 404 в процессе. Мы хотели бы не обращаться с этим напрямую и отдельно, если это возможно.

.. и я хотел бы знать, насколько это плохо. Я не ожидаю, что мои «красивые» URL-адреса будут размещены в Интернете (только визитные карточки), и у меня есть пример кода 404-перенаправления на полезный сайт, но я не хочу переходить к производству и есть проблема с браузером, который воспринимает начальный 404 слишком серьезно. Может кто-нибудь помочь мне понять, почему я не хочу использовать customErrors / 404 для перенаправления пользователей на страницу, которую они на самом деле хотят? *

Answer 1

Я создал систему тщеславия, используя 404 в качестве обработчика. Нет необходимости в 302 на моей стороне, так как 404 динамически загружает контент и возвращает его. Я полностью способен обрабатывать любые данные POST / GET и SERVER.

Отлично работает. Если вы заинтересованы, TarantulaHawk работает на SourceForge.

Answer 2

Основная проблема с использованием customeErrors в качестве обработчика ошибок 404 состоит в том, что каждый раз, когда customErrors получает ошибочный запрос, а не выдает ошибку 404 обратно в ваш браузер и сообщает вашему браузеру, что был ошибочный запрос, он вместо этого возвращает 302 Это означает, что страница была перемещена на какую-либо страницу customErrors. Это не плохо для большинства пользователей, потому что они не знают или даже не замечают разницы, проблема заключается в том, что веб-сканеры действительно знают разницу, и код состояния, который они получают, напрямую влияет на работу их индексации.

Рассмотрим сценарий, когда у вас есть страница на http://mysite.com/MyAwesomePageAboutStuff.aspx в течение некоторого периода времени, а затем однажды вы решаете, что она вам больше не нужна, и удалите файл. Если Google или другой сканер уже проиндексировал этот URL и возвращается к нему после его удаления, сканер получит код состояния 302 вместо ошибки 404, и из-за этого кода состояния сканер обновит URL-адрес страницы, чтобы он указывал на ваш адрес. Страница ошибки скорее удаляет несуществующую ссылку. Теперь, когда кто-то находит этот URL с помощью поисковой системы, он попадает на вашу страницу с ошибкой.

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

Смотрите здесь , чтобы найти подтверждающие данные.