Поведение веб-браузера клиента при обработке перенаправления 301

Question

RFC, похоже, предлагает клиенту постоянно кэшировать ответ: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

10.3.2 301 постоянно перемещено

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

ДОЛЖЕН быть указан новый постоянный URI по полю Расположение в ответе. Если метод запроса не был HEAD, субъект ответа ДОЛЖЕН содержать краткую гипертекстовую заметку с гиперссылка на новый URI.

Если код состояния 301 получен в ответ на запрос, отличный от GET или HEAD, пользовательский агент НЕ ДОЛЖЕН автоматически перенаправить запрос если это не может быть подтверждено пользователь, так как это может изменить условия, при которых запрос был выдано.

  Note: When automatically redirecting a POST request after
  receiving a 301 status code, some existing HTTP/1.0 user agents
  will erroneously change it into a GET request.

Мне трудно найти конкретную документацию для любого крупного браузера, в которой указано, как они с этим справляются.

Я начал копаться в исходном коде Firefox, но быстро заблудился.

Верен ли следующий сценарий для каких (если есть) браузеров, и есть ли полная документация для Firefox или IE, в которой говорится так же?:

Первый раз вокруг:

• 1.1. Пользователь вводит ссылку на сайт А или нажимает на ссылку, направленную на сайт А
• 1.2: Браузер интерпретирует ссылку на сайте A, впервые, без кеша. Отправляет GET на сайт A.
• 1.2: Сайт A отвечает 301 Redirect на сайт B
• 1.3. Браузер отправляет GET на сайт B.

В любое последующее время:

2.2: пользователь нажимает на ссылку, направленную на сайт A 2.2: Браузер видит, что из-за переадресации 301 в прошлом сайт A теперь должен быть сайтом B. 2.3: Без какого-либо запроса на сайте A браузер инициирует GET на сайте B.

Answer 1

Я выполнил некоторые тесты и обнаружил, что некоторые браузеры кэшируют результат 301:

Caches 301 result and skips contacting old address in future?

  Internet Explorer 7   no
  Firefox 3.0           no
  Chrome 4.0            yes
  Opera 10.01           yes for google.com, no for www.rnhart.net

Как я тестировал

Я использовал следующие два результата 301 для проверки:

• google.com возвращает 301 для www.google.com
• www.rnhart.net возвращает 301 для rnhart.net

Я запустил прокси-сервер на своем компьютере ( Proxomitron Naoko 4.2 со всеми отключенными фильтрами). В каждом браузере я устанавливаю настройки прокси, чтобы они указывали на мой собственный компьютер. Я очистил кеш браузера, затем несколько раз посетил старый адрес и заглянул в окно журнала прокси-сервера, чтобы увидеть, какие запросы сделал браузер.

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

Я проверил ввод старого адреса в поле адреса, доступ к старому адресу из закладки и доступ к старому адресу по ссылке на странице. Каждый браузер работал одинаково независимо от того, как был получен адрес.

---

[Я нашел этот вопрос во время исследования аналогичного вопроса суперпользователя: Изменили ли браузеры URL сохраненных закладок в ответ на перенаправление 301? ]

Answer 2

Вы можете использовать этот обходной путь :
Сделайте 302 редирект для пользователей и 301 только для поисковых систем. На стороне сервера просто проверьте пользовательский агент. Если это бот, сделайте 301 редирект. В противном случае сделайте 302.

Это не "золотой путь", но он прекрасно работает