После POST мне следует перенаправить 302 или 303?

Общим сценарием для веб-приложения является перенаправление после POST, который изменяет базу данных. Как перенаправление на вновь созданный объект базы данных после создания пользователем.

Похоже, что большинство веб-приложений используют 302 переадресации, но 303, кажется, правильная вещь в соответствии со спецификацией, если вы хотите, чтобы URL-адрес, указанный в перенаправлении, был получен с помощью GET. Технически, с 302, браузер должен получить указанный URL-адрес тем же методом, что и исходный url, который будет POST. Однако большинство браузеров этого не делают.

302 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3

303 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4

Так что я должен использовать 302 или 303?

Ответы

Ответ 1

Зависит.
303 и 307 ответов были добавлены в HTTP1.1.
Таким образом, клиентские агенты, которые строго соответствуют HTTP1.1 RFC, должны быть в порядке с ответом 303.
Но могут быть агенты, которые не полностью соответствуют или соответствуют требованиям HTTP1.0 и не смогут обрабатывать 303.
Поэтому, чтобы убедиться, что ответ вашего приложения можно обработать изящно большинством клиентских реализаций, я думаю, что 302 - самый безопасный вариант.
Выдержка из RFC-2616:

Примечание. Многие пользовательские агенты pre-HTTP/1.1 не понимаю 303       положение дел. Когда взаимодействие с такими клиентами вызывает озабоченность,       Вместо этого может использоваться код состояния 302, так как большинство агентов пользователя реагируют       к реакции 302, как описано здесь для 303.

Ответ 2

Правильный - 303.

Я использую его и не обнаружил проблем с совместимостью с UAs, новее Netscape 4 (1998, выпущен 17 лет назад).

Если вы используете 302, вы рискуете, что UA снова отправит POST на новый URL вместо перехода на GET.

Тем не менее, если вы беспокоитесь о клиентах HTTP/1.0 (которые не поддерживают vhosts и, вероятно, не смогут получить доступ к вашей странице в любом случае), вы должны включить HTML со ссылкой на новую страницу в теле 303 (такие веб-серверы, как Apache, уже это сделали).

Ответ 3

В большинстве серверных языков механизм перенаправления по умолчанию использует 302:

  • Java response.sendRedirect(..) использует 302
  • ASP.NET response.Redirect(..) использует 302
  • PHP header("Location: ..") использует 302
  • RoR redirect_to использует 302
  • и т.д..

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

Ответ 4

В теории вы (и весь мир) должны использовать 303, как вы уже отмечали. Но также большинство браузеров реагируют на 302, как будто они должны реагировать на 303. Таким образом, в целом, похоже, что не имеет значения, отправляете ли вы 302 или 303. В ссылке, которую вы указали для спецификации 303, есть интересная записка:

Примечание. Многие пользовательские агенты до HTTP/1.1 не понимают статус 303. Когда взаимодействие с такими клиентами вызывает озабоченность, вместо этого может использоваться код состояния 302, так как большинство агентов пользователя реагируют на ответ 302, как описано здесь для 303.

Важно отметить пользовательские агенты pre -HTTP/1.1, поэтому, возможно, это было важно некоторое время назад, но я не думаю, что это так.

Итак, в целом, это зависит от вас (я мог бы поспорить, что вы хотите, чтобы браузеры не изменяли свое поведение против 302 статусов никогда, из-за боязни взломать Интернет для своих пользователей).

Ответ 5

При предоставлении местоположения нового ресурса, созданного запросом POST, 201 ( "Создано" ) является подходящим ответом.

HTTP/1.1: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2

Протокол публикации Atom: http://tools.ietf.org/html/rfc5023#section-5.3

Это означает, что веб-браузер, вероятно, не будет перенаправляться на новый URL; пользователь должен следовать ссылке, чтобы перейти к новому элементу (эта ссылка может быть предоставлена ​​в тексте ответа, а также в заголовке Location).