Можно ли кэшировать методы POST в HTTP?
с очень простой семантикой кэширования: если параметры одинаковы (и URL-адрес такой же, конечно), то это хит. Это возможно? Рекомендовали?
9 ответов
соответствующего RFC 2616 В разделе 9.5 (POST) позволяет кэшировать ответ в сообщение POST, если вы используете соответствующие заголовки.
ответы на этот метод не кэшируются, если только ответ включает соответствующие поля заголовка Cache-Control или Expires. Однако, ответ 303 (см. Другой) можно использовать для направления агента пользователя получить кэшируемый ресурс.
обратите внимание, что RFC явно заявляет в разделе 13 (кэширование в HTTP), что кэш должен аннулировать соответствующую сущность после POST запрос.
некоторые методы HTTP должны вызывать кэш для аннулирования сущности. Это либо субъект, на который ссылается Запрос-URI, или по местоположению или Content-расположение заголовков (если есть). Эти методы:
- PUT - DELETE - POST
мне не ясно, как эти спецификации могут позволить осмысленный кэширование.
согласно разделу 9.5 RFC 2616:
"ответы на метод POST не cacheable, если ответ включает соответствующий контроль кэша или Истекает полей заголовка."
Итак, да, вы можете кэшировать ответ на запрос POST, но только если он поступает с соответствующими заголовками. В большинстве случаев вы не хотите кэшировать ответ. Но в некоторых случаях - например, если вы не сохраняете данные на сервере-это вполне уместно.
Примечание, однако многие браузеры, включая текущий Firefox 3.0.10, не будут кэшировать ответ POST независимо от заголовков. IE ведет себя более умно в этом отношении.
теперь, я хочу прояснить некоторую путаницу в документе RFC 2616 С. 13.10. Метод POST в URI не "аннулирует ресурс для кэширования", как некоторые заявили здесь. Он делает ранее кэшированную версию этого URI устаревшей, даже если его заголовки управления кэшем указывают на свежесть дольше продолжительность.
общие:
в принципе POST не является идемпотентной операцией. Поэтому вы не можете использовать его для кэширования. GET должна быть идемпотентной операцией, поэтому она обычно используется для кэширования.
см. раздел 9.1 HTTP 1.1 RFC 2616 S. 9.1.
кроме семантики метода GET:
сам метод POST семантически предназначен для публикации чего-либо на ресурсе. POST не может быть кэшируется, потому что если вы делаете что-то один раз против двух против трех раз, то вы изменяете ресурс сервера каждый раз. Каждый запрос имеет значение и должен быть доставлен на сервер.
сам метод PUT семантически предназначен для размещения или создания ресурса. Это идемпотентная операция, но она не будет использоваться для кэширования, потому что удаление могло произойти в то же время.
сам метод DELETE семантически предназначен для удаления ресурса. Это идемпотент операция, но она не будет использоваться для кэширования, потому что PUT мог произойти в то же время.
относительно кэширования на стороне клиента:
веб-браузер всегда будет пересылать ваш запрос, даже если он имеет ответ от предыдущей операции POST. Например, вы можете отправлять электронные письма с gmail через пару дней. Они могут быть одним и тем же предметом и телом, но оба письма должны быть отправлены.
по поводу кэширования прокси-сервера:
A прокси-сервер HTTP, который пересылает ваше сообщение на сервер, никогда не кэширует ничего, кроме запроса GET или HEAD.
по поводу кэширования сервера:
сервер по умолчанию не будет автоматически обрабатывать запрос POST, проверяя его кэш. Но, конечно, запрос POST может быть отправлен в ваше приложение или надстройку, и у вас может быть свой собственный кэш, который Вы читаете, когда параметры одинаковы.
аннулирование a ресурс:
проверка HTTP 1.1 RFC 2616 S. 13.10 показывает, что метод POST должен аннулировать ресурс для кэширования.
Если вы кэшируете ответ POST, он должен быть в направлении веб-приложения. Это то, что подразумевается под "ответами на этот метод недоступны, если ответ не включает соответствующие поля заголовка Cache-Control или Expires."
можно с уверенностью предположить, что приложение, которое знает, являются ли результаты поста идемпотентными, решает, присоединять ли необходимые и правильные заголовки управления кэшем. Если заголовки, предлагающие кэширование, разрешены присутствует, приложение говорит вам, что сообщение, на самом деле, супер-GET; что использование POST было необходимо только из-за количества ненужных и нерелевантных (для использования URI в качестве ключа кэша) данных, необходимых для выполнения идемпотентной операции.
следующие GET могут быть поданы из кэша при этом предположении.
приложение, которое не может прикрепить необходимые и правильные заголовки, чтобы различать доступную и недоступную почту ответы виноваты в любых недопустимых результатах кэширования.
тем не менее, каждый пост, который попадает в кэш, требует проверки с использованием условных заголовков. Это необходимо для обновления содержимого кэша, чтобы избежать того, чтобы результаты POST не отражались в ответах на запросы до истечения срока службы объекта.
Если это что-то, что фактически не изменяет данные на вашем сайте, это должен быть запрос GET. Даже если это форма, вы все равно можете установить ее как запрос get. Хотя, как отмечают другие, вы можете кэшировать результаты поста, это не имеет семантического смысла, потому что сообщение по определению изменяет данные.
конечно, это возможно. Если вы хотите поймать почтовые запросы, отправленные на ваш сервер, и кэшировать данные, отправленные обратно для повторной отправки позже-без проблем.
хитрая часть приходит в отношении "государства". Как вы решите, что данные, которые вы хотите отправить обратно пользователю, действительно должны быть одинаковыми? Что делать, если его cookies изменились - это меняет данные, которые вы хотите отправить обратно?
Как насчет того, если пользователь сделал запрос POST на вашу домашнюю страницу, и с последнего раза он сделал это, другой пользователь отправил ему сообщение (используя некоторую систему внутри вашего сайта.) Вам нужно будет определить это как изменение состояния и отправить новую версию вашей домашней страницы с уведомлением о сообщении пользователю при следующей загрузке домашней страницы. Даже если параметры POST одинаковы.
Марк Ноттингем проанализировал, когда возможно кэшировать ответ сообщения. Обратите внимание, что последующие запросы, которые хотят воспользоваться кэшированием, должны быть запросами GET или HEAD. См. также httpbis
сообщения не имеют дело с представлениями идентифицированного состояния, 99 раз из 100. Однако есть один случай, когда это происходит; когда сервер выходит из его способ сказать, что этот ответ POST является представлением его URI, установив Content - заголовок местоположения, который совпадает с запросом УРИ. Когда это происходит, ответ 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. Невероятно!
POST используется в stateful Ajax. Возврат кэшированного ответа для сообщения уничтожает канал связи и побочные эффекты получения сообщения. Это очень, очень плохо. Это также настоящая боль, чтобы выследить. Настоятельно не рекомендуется.
тривиальным примером может быть сообщение о том, что в качестве побочного эффекта вы платите свою зарплату $10,000 на текущей неделе. Вы не хотите, чтобы получить " хорошо,это прошло!- страница, которая была сохранена на прошлой неделе. Других, более сложных случаях результат в подобной веселости.