В чем разница между перенаправлением 302 и 307?

Question

В чем разница между 302 FOUND и 307 TEMPORARY REDIRECT HTTP-ответом?

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

Answer 1

307 возникло из-за того, что пользовательские агенты приняли поведение de facto , чтобы принимать запросы POST, которые получают ответ 302, и отправлять запрос GET в заголовок ответа Location.

Это некорректное поведение & mdash; только a 303 должно заставить POST превратиться в GET. Пользовательские агенты должны (но не) придерживаться метода POST при запросе нового URL, если исходный запрос POST возвратил 302.

307 был введен для того, чтобы серверы давали понять агенту пользователя, что изменение метода не должно выполняться клиентом при использовании заголовка ответа Location.

Answer 2

Разница касается перенаправления запросов POST, PUT и DELETE и ожиданий сервера в отношении поведения агента пользователя (RFC 2616):

Примечание. RFC 1945 и RFC 2068 указывают, что клиенту не разрешено изменить метод на перенаправленный запрос. Тем не менее, большинство существующих пользователей реализации агента обрабатывают 302 как это был 303 ответ, выполняя ПОЛУЧИТЬ значение поля Location независимо от первоначального запроса метод. Коды состояния 303 и 307 были добавлены для серверов, которые желают чтобы однозначно понять, какой реакции ожидается от клиент.

Также читайте статью в Википедии о 30x кодах перенаправления .

Answer 3

Хорошим примером действия 307 Internal Redirect является случай, когда Google Chrome обнаруживает HTTP-вызов домена, который, как он знает, требует строгой транспортной безопасности.

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

Answer 4

ОЖИДАЕТСЯ для 302: перенаправление использует тот же метод запроса POST для NEW_URL

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL

ACTUAL для 302, 303: метод запроса перенаправления изменений с POST на GET для NEW_URL

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)
CLIENT POST OLD_URL -> SERVER 303 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)

ACTUAL для 307: перенаправление использует тот же метод запроса POST для NEW_URL

CLIENT POST OLD_URL -> SERVER 307 NEW_URL -> CLIENT POST NEW_URL

Answer 5

• 301: постоянное перенаправление: URL устарел и его следует заменить. Браузеры будут кешировать это.
  Пример использования: URL-адрес перемещен с /register-form.html на signup-form.html.
  Метод изменится на GET в соответствии с RFC 7231: «По историческим причинам пользовательский агент МОЖЕТ изменить метод запроса с POST наGET для последующего запроса. "
• 302: временное перенаправление.Используйте только для клиентов HTTP / 1.0. Этот код состояния не должен изменять метод, но браузеры все равно сделали это.В RFC говорится: «Многие пользовательские агенты до HTTP / 1.1 не понимают [303]. Когда возникает проблема взаимодействия с такими клиентами, вместо этого можно использовать код состояния 302, поскольку большинство пользовательских агентов реагируют на ответ 302, как описано здесь.за 303. "Конечно, некоторые клиенты могут реализовать его в соответствии со спецификацией, поэтому, если совместимость с такими древними клиентами не является реальной проблемой, 303 лучше для согласованных результатов.
• 303: временное перенаправление, изменение методаGET.
  Пример использования: , если браузер отправил POST на /register.php, то теперь загрузка (GET) /success.html.
• 307: временнаяперенаправление, повторяя запрос одинаково.
  Пример использования: если браузер отправил POST на /register.php, то это говорит ему, чтобы повторить POST на /signup.php.
• 308: постоянное перенаправление, идентичное повторение запроса. Если 307 - это «без изменения метода» 303, то это состояние 308 - это «без изменения метода» 301.

RFC 7231 (с 2014 г.) очень хорошо читается и не слишком многословен.Если вы хотите знать точный ответ, рекомендуем прочитать.В некоторых других ответах используется RFC 2616 от 1999 года, но ничего не изменилось.

RFC 7238 определяет статус 308.Он считается экспериментальным, но он уже поддерживается всеми основными браузерами в 2016 году.

Answer 6

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

Дополнительную информацию можно найти в разделе 3.1 из Комплексный формальный анализ безопасности OAuth 2.0 .

Авторы данной статьи предлагают следующее:

Fix. Вопреки текущей формулировке в стандарте OAuth, точный метод перенаправления не является деталью реализации, но необходим для безопасности OAuth. В стандарте HTTP ( RFC 7231 ) однозначно определено только перенаправление 303 для отбрасывания тела запроса HTTP POST. Все остальные коды состояния перенаправления HTTP, включая наиболее часто используемый 302, оставляют браузеру возможность сохранить запрос POST и данные формы. На практике браузеры обычно переписывают запрос GET, тем самым отбрасывая данные формы, за исключением 307 перенаправлений. Поэтому стандарт OAuth должен требовать 303 перенаправления для шагов, упомянутых выше, чтобы решить эту проблему.

Answer 7

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

Например, * Firefox и Opera будут запрашивать у пользователя разрешение на перенаправление, тогда как Chrome, IE и Safari будут выполнять перенаправление прозрачно.

_{* за Пуленепробиваемые SSL и TLS (стр. 192).}