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

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

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

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

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

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

Вопрос в том:

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

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


person pinkgothic    schedule 17.03.2010    source источник
comment
хороший вопрос, меня тоже это интересует   -  person Patrick Cornelissen    schedule 17.03.2010


Ответы (1)


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

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

302 не подходит по моему мнению:

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

Однако мне больше всего нравится 303 see other:

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

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

person Pekka    schedule 17.03.2010
comment
Теперь, когда вы упомянули об этом... "See Other" звучит потрясающе. Я немного изучу совместимость, посмотрим, смогу ли я уйти от этого. Что касается 301, я сомневаюсь в этом, потому что, если вы интерпретируете это буквально, вы фактически аннулируете необходимость промежуточной страницы. Конечно, ни один браузер не настолько скуп, так что, наверное, все в порядке, но, может быть, вы понимаете мою нерешительность. :) - person pinkgothic; 17.03.2010
comment
Просто быстрое продолжение, похоже, я могу использовать 303. Так что большое спасибо! - person pinkgothic; 17.03.2010
comment
303 широко используется в семантической сети для согласования содержимого в результате разрешения W3C TAG httpRange-14 lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html Обычно хорошо спроектированный клиент автоматически выполняет GET, когда получает ответ 303, чтобы получить фактический ресурс, например, .Net framework делает это автоматически - person RobV; 18.03.2010