Перенаправление внешней ссылки, не связанной с SEO и защитой от спуфинга:Код состояния?

Question

Я прочитал несколько документов о различных кодах статуса перенаправления HTTP, но все они были очень ориентированы на SEO.Теперь у меня возникла проблема, которую поисковые системы не учитывают, поскольку соответствующий раздел сайта не доступен для публичного просмотра.

Тем не менее, мы хотим, чтобы наш веб-сайт был максимально точным и полезным с метаданными, особенно из соображений доступности.

Теперь наше приложение принимает внешние ссылки, предоставленные третьими лицами, и направляет их на анти-спуфинговую страницу с заявлением об отказе от ответственности.Поскольку эта страница перенаправления также может быть эффективно встроена через вызов Ajax в определенных созвездиях, мы также хотим удалить любые параметры запроса из реферера (в целях конфиденциальности;целевой сайт не имеет права выяснять, на какой внутренней странице был пользователь раньше).

Для этого кнопка подтверждения запускает серверный скрипт, который, в свою очередь, перенаправляет (а не просто открывает страницу для пользователя).

В том числе и о том, почему наша страница заявления об отказе от спуфинга в конечном итоге вызывает перенаправление.

Вопрос в том:

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

Я имею в виду 302 - но поскольку нет смысла пытаться добавить страницу в закладки (она защищена токеном crsf), то, вероятно, и в 301 нет никакого вреда, не так ли?Поэтому мне интересно, есть ли у меня причина предпочитать одно другому.

Answer 1

Хм. Вот список. 301 звучит нормально (выделено мной):

Запрошенному ресурсу присвоен новый постоянный URI. и любые будущие ссылки на этот ресурс ДОЛЖНЫ использовать один из возвращенных URI..Клиенты с возможностями редактирования ссылок должны автоматически повторно связывать ссылки на Request-URI с одной или несколькими новыми ссылками, возвращаемыми сервером, где это возможно.

302 на мой взгляд не подходит:

Запрошенный ресурс временно находится под другим URI.

Однако мой любимый 303 see other:

Ответ на запрос можно найти по другому URI, и его СЛЕДУЕТ получить с помощью метода GET для этого ресурса..Этот метод существует в первую очередь для того, чтобы выходные данные активируемого POST сценария перенаправляли пользовательский агент на выбранный ресурс.Новый URI не заменяет ссылку на первоначально запрошенный ресурс.

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