Можно ли кэшировать методы POST в HTTP?
с очень простой семантикой кэширования: если параметры одинаковы (и URL-адрес, конечно же, один и тот же), то это хит. Это возможно? Рекомендуется?
9 ответов:
соответствующего RFC 2616 В разделе 9.5 (POST) позволяет кэширование ответ к почтовому сообщению, если вы используете соответствующие заголовки.
ответы на этот метод не могут быть кэшированы, если только ответ включает соответствующие поля заголовка Cache-Control или Expires. Однако, ответ 303 (см. Другое) может быть использован для направления агента пользователя получение кэшируемого ресурса.
обратите внимание, что RFC явно заявляет в разделе 13 (кэширование в HTTP), что кэш должен аннулировать соответствующую сущность после POST запрос.
некоторые методы HTTP должны вызывать кэш для аннулирования сущности. Это либо объект, на который ссылается Запрос-URI, или по местоположению или Содержимое-расположение заголовков (если есть). Эти методы:
- PUT - DELETE - POSTмне не ясно, как эти спецификации могут иметь смысл кэширование.
согласно разделу 9.5 RFC 2616:
"ответы на метод POST не cacheable, если только ответ включает в себя соответствующий кэш-контроль или Истекает срок действия полей заголовка."
Итак, да, вы можете кэшировать ответ на запрос POST, но только если он поступает с соответствующими заголовками. В большинстве случаев вы не хотите кэшировать ответ. Но в некоторых случаях - например, если вы не сохраняете никаких данных на сервере - это вполне уместно.
Примечание, однако многие браузеры, включая текущий Firefox 3.0.10, не будут кэшировать ответ POST независимо от заголовков. Т. е. ведет себя более грамотно в этом отношении.
теперь, я хочу прояснить некоторую путаницу в документе RFC 2616 С. 13.10. Метод POST на URI не "аннулирует ресурс для кэширования", как некоторые из них заявили здесь. Это делает ранее кэшированную версию этого URI устаревшей, даже если его заголовки управления кэшем указывают на свежесть более длинного продолжительность.
общие:
в принципе POST не является идемпотентной операцией. Поэтому вы не можете использовать его для кэширования. GET должна быть идемпотентной операцией, поэтому она обычно используется для кэширования.
пожалуйста, смотрите раздел 9.1 HTTP 1.1 RFC 2616 S. 9.1.
кроме семантики метода GET:
сам метод POST семантически предназначен для публикации чего-либо на ресурсе. Пост не может быть кэшируется, потому что если вы делаете что-то один раз против двух против трех раз, то вы изменяете ресурс сервера каждый раз. Каждый запрос имеет значение и должен быть доставлен на сервер.
сам метод PUT семантически предназначен для размещения или создания ресурса. Это идемпотентная операция, но она не будет использоваться для кэширования, потому что удаление могло произойти в то же время.
сам метод DELETE семантически предназначен для удаления ресурса. Это идемпотент операция, но она не будет использоваться для кэширования, потому что PUT мог произойти в то же время.
Что касается кэширования на стороне клиента:
веб-браузер всегда будет пересылать ваш запрос, даже если он имеет ответ от предыдущей операции POST. Например, вы можете отправлять электронные письма с gmail через пару дней. Они могут быть одной и той же темой и телом, но оба письма должны быть отправлены.
Что касается кэширования прокси:
A прокси-сервер HTTP, который пересылает ваше сообщение на сервер, никогда не будет кэшировать ничего, кроме запроса GET или HEAD.
Что касается кэширования сервера:
сервер по умолчанию не будет автоматически обрабатывать запрос POST путем проверки его кэша. Но, конечно, запрос POST может быть отправлен в ваше приложение или надстройку, и вы можете иметь свой собственный кэш, который Вы читаете, когда параметры одинаковы.
аннулирование a ресурс:
проверка HTTP 1.1 RFC 2616 S. 13.10 показывает, что метод POST должен аннулировать ресурс для кэширования.
Если вы кэшируете ответ POST, он должен быть в направлении веб-приложения. Это то, что подразумевается под "ответами на этот метод не являются cachable, если ответ не включает соответствующие поля заголовка Cache-Control или Expires."
можно смело предположить, что приложение, которое знает, являются ли результаты сообщения идемпотентными, решает, следует ли прикреплять необходимые и правильные заголовки управления кэшем. Если заголовки, которые предлагают кэширование разрешено присутствуют, приложение говорит вам, что сообщение на самом деле является супер-GET; что использование POST было необходимо только из-за количества ненужных и неуместных (для использования URI в качестве ключа кэша) данных, необходимых для выполнения идемпотентной операции.
следующие GET могут быть поданы из кэша в соответствии с этим предположением.
приложение, которое не может прикрепить необходимые и правильные заголовки для различения между cachable и non-cachable POST ответы виноваты в любых недопустимых результатах кэширования.
тем не менее, каждый пост, который попадает в кэш, требует проверки с использованием условных заголовков. Это необходимо для обновления содержимого кэша, чтобы избежать того, чтобы результаты записи не отражались в ответах на запросы до истечения срока действия объекта.
Если это что-то, что на самом деле не изменяет данные на вашем сайте, это должен быть запрос GET. Даже если это форма, вы все равно можете установить ее как запрос get. Хотя, как отмечают другие, вы можете кэшировать результаты публикации, это не будет иметь семантического смысла, потому что запись по определению изменяет данные.
конечно, это возможно. Если вы хотите поймать POST-запросы, отправленные на ваш сервер, и кэшировать данные, отправленные обратно для повторной отправки позже-не потейте.
хитрая часть приходит в отношении "государства". Как вы решаете данные, которые вы хотите отправить обратно пользователю действительно должны быть одинаковы? Что делать, если его куки изменились - это меняет данные, которые вы хотите отправить обратно?
Как насчет того, если пользователь сделал запрос на вашу домашнюю страницу, и с тех пор, как он сделал это в последний раз, другой пользователь отправил ему сообщение (используя какую-то систему внутри вашего сайта.) Вам нужно будет определить это как изменение состояния и отправить новую версию своей домашней страницы с уведомлением о сообщении пользователю при следующей загрузке домашней страницы. Даже если параметры записи одинаковы.
Марк Ноттингем проанализировал, когда можно кэшировать ответ сообщения. Обратите внимание, что последующие запросы, которые хотят воспользоваться преимуществами кэширования, должны быть GET или HEAD requests. Смотрите также httpbis
сообщения не имеют дело с представлениями идентифицированного состояния, в 99 случаях из 100. Однако есть один случай, когда это происходит; когда сервер выходит из строя его способ сказать, что этот ответ на сообщение является представлением его URI, установив Заголовок Content-Location, который совпадает с запросом УРИ. Когда это происходит, ответ POST похож на ответ GET к тому же URI; он может быть кэширован и повторно использован-но только для будущего запрос get.
с firefox 27.0 & с httpfox, 19 мая 2014 года, я видел одну строку этого: 00:03:58.777 0.488 657 (393) сообщение (кэш) текст / html https://users.jackiszhp.info/S4UP
очевидно, что ответ метода post кэшируется, и он также находится в https. Невероятно!
сообщение используется в состоянии Ajax. Возврат кэшированного ответа для сообщения уничтожает канал связи и побочные эффекты получения сообщения. Это очень и очень плохо. Это также настоящая боль, чтобы выследить. Очень рекомендую против.
тривиальным примером может быть сообщение о том, что в качестве побочного эффекта вы платите свою зарплату $10,000 на текущей неделе. Вы не хотите, чтобы получить "хорошо, это прошло!"страница назад, которая была сохранена на прошлой неделе. Другие, более сложные реальные случаи результат в подобном веселье.