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

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

10.3.2 301 Перемещено на постоянной основе

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

Новый постоянный URI ДОЛЖЕН быть предоставлен по полю Location в ответе. Если метод запроса не был 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: Пользователь вводит ссылку на сайт A или нажимает ссылку, направленную на сайт A
1.2: Браузер интерпретирует ссылку на сайте A, первый раз, без кеша. Отправляет GET на сайт A.
1.2: Сайт A отвечает 301 переадресацией на сайт B
1.3: Браузер отправляет GET на сайт B.

Любые последующие времена:

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

Ответ 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 переадресацию?]

Ответ 2

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

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