Redirect after POST
Немного о тонкостях протокола HTTP.
Q: Нужно ли делать редирект после обработки данных, полученных при отправке формы методом POST?
Q: Какой статус выдавать в редиректе — 302, 303 или 307?
A:
По логике редирект надо выдавать всегда, когда мы хотим избежать двойной отправки данных при нажатии в браузере на reload. Иногда двойная отправка бывает полезной (при реализации визардов), но в большинстве случаев — потенциально опасна (например, при случайном нажатии F5 в банковской системе после транзакции произойдет повторное списание денег со счета).
Большинство существующих веб-приложений выдает статус 302 (Found), и большинство юзер-агентов именно этот статус воспринимают как автоматическое перенаправление на другой урл.
Если вы внимательно прочитаете RFC 2616, то обнаружите, что юзер-агенту категорически запрещается автоматически редиректить пользователя на этот урл:
К сожалению, большинство приложений исторически забили на стандарт, и обрабатывают этот статус так же, как 303 (почему к сожалению — объясню ниже).
Для автоматического перенаправления пользователя на новый урл как раз и предназначен статус 303 (See Other):
Статус 307 (Temporary Redirect) отличается от 303 по смыслу: если 303 указывает на новый урл, то 307 — на альтернативный, тот урл, по которому рекомендуется обращаться в дальнейшем вместо первоначального:
Этот статус используется редко, и опять же, стандарт запрещает автоматический переход в ответ на запрос методом POST, поэтому забудем о нем.
Теперь, о самом главном. Все бы было хорошо, если бы не особенности реализации некоторых браузеров. Вот тут мы сталкиваемся с такими проблемами:
Хорошая новость в том, что таких браузеров абсолютное меньшинство, и в основном замечены они были на просторах вапа, среди производителей мобильных девайсов.
Но все-таки, мы ведь хотим предоставить качественный сервис всем пользователям без исключения?
Одной из особенностей статуса 303 является то, что по стандарту урл, на который осуществляется переход, должен запрашиваться по протоколу GET:
Можно воспользоваться этой особенностью, а можно придумать более универсальное решение (тем более глагол SHOULD в rfc вносит не строго обязательный характер):
Кроме того, стандартом настоятельно рекомендуется сопровождать тело редиректов документом со ссылкой на перенаправляемую страницу, а для метода POST желательно добавить пояснение: какие действия нужно выполнить, чтобы, перейдя по ссылке, повторить запрос. Это нужно для совместимости между старыми, ошибочными, или неполными реализациями протокола.
Пару слов про другие статусы.
301 (Moved Permanently) — подразумевается, что для одного и того же запроса выдается сервером постоянно, всегда, вне зависимости от каких-либо других факторов, в отличие от 307 — который может быть выдан в зависимости от некоторых внешних условий. Этот статус в большинстве юзер-агентов полностью не поддерживается, браузеры не подменяют после редиректа ссылки так, как это следовало бы делать по стандарту, и скорее всего, обрабатывают его так же, как и 302.
304 (Not Modified) связан с кешированием, об этих особенностях постараюсь рассказать в следующий раз.
300 (Multiple Choices) предназначен для выбора одного урла из нескольких альтернативных, в жизни реального применения я не встречал.
305 (Use Proxy) предназначен для принудительного направления запроса через прокси, на практике не встречал.
306 (Unused) — уже не используется.
Продолжение следует.
Q: Нужно ли делать редирект после обработки данных, полученных при отправке формы методом POST?
Q: Какой статус выдавать в редиректе — 302, 303 или 307?
A:
По логике редирект надо выдавать всегда, когда мы хотим избежать двойной отправки данных при нажатии в браузере на reload. Иногда двойная отправка бывает полезной (при реализации визардов), но в большинстве случаев — потенциально опасна (например, при случайном нажатии F5 в банковской системе после транзакции произойдет повторное списание денег со счета).
Большинство существующих веб-приложений выдает статус 302 (Found), и большинство юзер-агентов именно этот статус воспринимают как автоматическое перенаправление на другой урл.
Если вы внимательно прочитаете RFC 2616, то обнаружите, что юзер-агенту категорически запрещается автоматически редиректить пользователя на этот урл:
If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user[…]
К сожалению, большинство приложений исторически забили на стандарт, и обрабатывают этот статус так же, как 303 (почему к сожалению — объясню ниже).
Для автоматического перенаправления пользователя на новый урл как раз и предназначен статус 303 (See Other):
This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource.
Статус 307 (Temporary Redirect) отличается от 303 по смыслу: если 303 указывает на новый урл, то 307 — на альтернативный, тот урл, по которому рекомендуется обращаться в дальнейшем вместо первоначального:
The requested resource resides temporarily under a different URI.
Этот статус используется редко, и опять же, стандарт запрещает автоматический переход в ответ на запрос методом POST, поэтому забудем о нем.
Теперь, о самом главном. Все бы было хорошо, если бы не особенности реализации некоторых браузеров. Вот тут мы сталкиваемся с такими проблемами:
- некоторые старые юзер-агенты так и не научились понимать HTTP/1.1, в котором отсутствует статус 303 (предыдущая версия стандарта HTTP/1.0 описана в RFC 1945, принятом на год раньше RFC 2068, где этот статус уже был, но пока не было 307),
- некоторые юзер-агенты все-таки свято соблюдают стандарты, и поэтому выдают предупреждение в ответ на редирект 302 после отправки формы методом POST,
- некоторые юзер-агенты еще и интерпретируют стандарты по-своему, например, после выдачи редиректа они повторяют отправку данных через POST (!) на новый урл, вызывая непредсказуемое поведение.
Хорошая новость в том, что таких браузеров абсолютное меньшинство, и в основном замечены они были на просторах вапа, среди производителей мобильных девайсов.
Но все-таки, мы ведь хотим предоставить качественный сервис всем пользователям без исключения?
Одной из особенностей статуса 303 является то, что по стандарту урл, на который осуществляется переход, должен запрашиваться по протоколу GET:
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource.
Можно воспользоваться этой особенностью, а можно придумать более универсальное решение (тем более глагол SHOULD в rfc вносит не строго обязательный характер):
- проанализировать версию HTTP протокола, которую запросил пользователь,
- отказаться от статуса 302 для клиентов с версией 1.1 в пользу статуса 303,
- всегда добавлять в урл для редиректа параметры, позволяющие предотвратить непредсказуемую повторную отправку при редиректе (например, в чате, при редиректе «на самого себя»).
Кроме того, стандартом настоятельно рекомендуется сопровождать тело редиректов документом со ссылкой на перенаправляемую страницу, а для метода POST желательно добавить пояснение: какие действия нужно выполнить, чтобы, перейдя по ссылке, повторить запрос. Это нужно для совместимости между старыми, ошибочными, или неполными реализациями протокола.
Пару слов про другие статусы.
301 (Moved Permanently) — подразумевается, что для одного и того же запроса выдается сервером постоянно, всегда, вне зависимости от каких-либо других факторов, в отличие от 307 — который может быть выдан в зависимости от некоторых внешних условий. Этот статус в большинстве юзер-агентов полностью не поддерживается, браузеры не подменяют после редиректа ссылки так, как это следовало бы делать по стандарту, и скорее всего, обрабатывают его так же, как и 302.
304 (Not Modified) связан с кешированием, об этих особенностях постараюсь рассказать в следующий раз.
300 (Multiple Choices) предназначен для выбора одного урла из нескольких альтернативных, в жизни реального применения я не встречал.
305 (Use Proxy) предназначен для принудительного направления запроса через прокси, на практике не встречал.
306 (Unused) — уже не используется.
Продолжение следует.