Можно ли кэшировать методы POST в HTTP?

Question

С очень простой семантикой кеширования: если параметры одинаковые (и, конечно, один и тот же URL), то это хит. Это возможно? Рекомендуемые?

Answer 1

Соответствующий RFC 2616 в разделе 9.5 (POST) позволяет кэшировать ответ на сообщение POST, если вы используете соответствующие заголовки.

Ответы на этот метод не кэшируются, если ответ не включает соответствующую Cache-Control или просрочен полей заголовок. Тем не менее, ответ 303 (см. Другой) можно использовать для направления пользовательского агента на для получения кэшируемого ресурса.

Обратите внимание, что тот же RFC прямо говорится в статье 13 (Caching в HTTP), что кэш должен аннулируют соответствующий объект после запроса в POST .

Некоторые HTTP-методы ДОЛЖНЫ вызвать кеш для аннулирования объекта. Это либо объект, на который ссылается Request-URI, или по местоположению или Заголовки содержимого-местоположения (если они есть). Эти методы являются:

- PUT 
    - DELETE 
    - POST 

Это мне не ясно, каким образом эти характеристики могут позволить значимого кэширования.

Answer 2

Конечно, это возможно. Если вы хотите поймать POST-запросы, отправленные на ваш сервер, и кэшировать данные, отправленные обратно, чтобы повторно отправить их позже - нет пота.

Незначительная часть приходит в отношении «состояния». Как вы решаете, данные, которые вы хотите отправить обратно пользователю, должны быть одинаковыми? Что делать, если его файлы cookie изменились - это изменит данные, которые вы хотите отправить обратно?

Как насчет того, выполнил ли пользователь запрос POST на вашей домашней странице, и с тех пор, как в последний раз он это сделал, другой пользователь отправил ему сообщение (используя некоторую систему внутри вашего сайта.) Вам нужно было бы идентифицировать это как изменение и отправьте новую версию своей домашней страницы с уведомлением о сообщении пользователю в следующий раз, когда он загрузит главную страницу. Даже если параметры POST совпадают.

Answer 3

Если это то, что фактически не изменяет данные на вашем сайте, это должен быть запрос GET. Даже если это форма, вы все равно можете установить ее как запрос на получение. Хотя, как и другие, вы можете кэшировать результаты POST, это не будет иметь смысловой смысл, потому что POST по определению изменяет данные.

Answer 4

Всего:

В основном POST is not an idempotent operation. Поэтому вы не можете использовать его для кеширования. GET должна быть идемпотентной, поэтому она обычно используется для кэширования.

См. Раздел 9.1 раздела HTTP 1.1 RFC 2616 S. 9.1.

Кроме семантики метод GET по:

Сам метод POST семантически означает, чтобы получить возможность отправлять что-то к ресурсу.POST нельзя кэшировать, потому что если вы делаете что-то один раз vs дважды vs три раза, вы каждый раз изменяете ресурс сервера. Каждый запрос имеет значение и должен быть доставлен на сервер.

Сам метод PUT семантически предназначен для создания или создания ресурса. Это идемпотентная операция, но она не будет использоваться для кэширования, потому что за это время мог быть DELETE.

Метод DELETE сам по себе семантически предназначен для удаления ресурса. Это идемпотентная операция, но она не будет использоваться для кэширования, потому что PUT мог произойти за это время.

Что касается кэширования на стороне клиента:

Веб-браузер будет всегда вперед ваш запрос, даже если он имеет ответ от операции предыдущего POST. Например, вы можете отправлять письма с помощью gmail через пару дней. Они могут быть одним и тем же предметом и телом, но оба письма должны быть отправлены.

Что касается кэширования прокси:

HTTP-сервер прокси, который пересылает сообщение к серверу не ничего, кроме GET или запрос HEAD, никогда не кэшировать бы.

Что касается кэширования сервера:

Сервер по умолчанию не будет автоматически обрабатывать запрос POST с помощью проверки его кэш. Но, конечно, запрос POST может быть отправлен в ваше приложение или надстройку, и вы можете иметь свой собственный кеш, который вы читаете, когда параметры одинаковы.

утратившей сила ресурса:

Проверка HTTP 1.1 RFC 2616 S. 13.10 показывает, что метод POST должен аннулировать ресурс для кэширования.

Answer 5

В соответствии с RFC 2616 Раздел 9.5:

"Ответы на POST метод не кэшируемым, если ответ не включает соответствующие Cache-Control или Истекает поля заголовка."

Итак, да, вы можете кэшировать ответ запроса POST, но только если он поступает с соответствующими заголовками. В большинстве случаев вы не хотите кэшировать ответ. Но в некоторых случаях - например, если вы не сохраняете какие-либо данные на сервере - это вполне уместно.

Обратите внимание, что многие браузеры, включая текущий Firefox 3.0.10, не будут кэшировать ответ POST независимо от заголовков. IE ведет себя более разумно в этом отношении.

Теперь я хочу прояснить некоторые путаницы в отношении RFC 2616 S. 13.10. Метод POST в URI не «делает недействительным ресурс для кэширования», как некоторые из них заявили здесь. Это делает ранее кэшированную версию этого URI устаревшей, даже если ее заголовки управления кешем указывают на свежесть более длительной продолжительности.

Answer 6

POST используется в состоянии Ajax. Возврат кэшированного ответа для POST поражает канал связи и побочные эффекты приема сообщения. Это очень плохо. Это также настоящая боль, чтобы отследить. Очень рекомендуется.

Тривиальный пример - это сообщение, которое в качестве побочного эффекта выплачивает вашу зарплату в размере 10 000 долларов на текущей неделе. Вы НЕ хотите, чтобы «ОК, все прошло!» страница назад, которая была кэширована на прошлой неделе. Другие, более сложные дела в реальном мире приводят к сходному веселью.

Answer 7

С светлячок 27,0 & с HTTPFox, 19 мая 2014 года, я увидел одну строчку этого: 00: 03: 58,777 0,488 657 (393) POST (Cache) текст/html https://users.jackiszhp.info/S4UP

Очевидно, что ответ метода post кэшируется, и он также находится в https. Невероятно!

Answer 8

Марк Ноттингем проанализировал, когда возможно кэшировать ответ POST. Обратите внимание, что последующие запросы, которые хотят использовать кеширование, должны быть запросами GET или HEAD. Смотрите также httpbis

постов не занимаются в представлениях идентифицированного состояния, 99 раз из 100. Однако, есть один случай, когда он делает; когда сервер выходит из , его способ сказать, что этот ответ POST представляет собой представление его URI, , установив заголовок Content-Location, который совпадает с запросом URI. Когда это произойдет, ответ POST похож на ответ GET на тот же URI; его можно кэшировать и повторно использовать, но только для будущего Запросы GET.

https://www.mnot.net/blog/2012/09/24/caching_POST.

Answer 9

Если вы кешируете ответ POST, он должен находиться в направлении веб-приложения. Это означает, что «Ответы на этот метод не являются кэшируемыми, если только ответ не включает соответствующие поля заголовка Cache-Control или Expires».

Можно с уверенностью предположить, что приложение, которое знает, являются ли или нет результаты POST, идемпотентным, решает, нужно ли присоединять необходимые и правильные заголовки управления кешем. Если присутствуют заголовки, предлагающие кэширование, приложение сообщает вам, что POST на самом деле является супер-GET; что использование POST было необходимо только из-за ненужного и неуместного (использования URI в качестве ключа кэш-памяти) данных, необходимых для выполнения идемпотентной операции.

В соответствии с этим допущением можно использовать кеширование из кеша.

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

При этом каждый POST, который попадает в кеш, требует проверки с использованием условных заголовков. Это необходимо для обновления содержимого кеша, чтобы избежать отражения результатов POST в ответах на запросы до истечения срока жизни объекта.