С очень простой семантикой кеширования: если параметры одинаковые (и, конечно, один и тот же URL), то это хит. Это возможно? Рекомендуется?
Можно ли кэшировать методы POST в HTTP?
Ответ 1
Соответствующий RFC 2616 в разделе 9.5 (POST) позволяет кэшировать ответ на сообщение POST, если вы используете соответствующие заголовки.
Ответы на этот метод не подлежат кэшированию, если только ответ включает соответствующие поля заголовка Cache-Control или Expires. Однако, ответ 303 (см. другой) можно использовать для направления пользовательского агента на получить ресурс, кэшируемый.
Обратите внимание, что те же самые RFC-состояния явно в разделе 13 (Кэширование в HTTP), что кэш должен аннулировать соответствующий объект после запроса POST .
Некоторые HTTP-методы ДОЛЖНЫ кеш, чтобы аннулировать объект. Это либо субъект, на который ссылается Request-URI, или по местоположению или Заголовки Content-Location (если они есть). Эти методы:
- PUT - DELETE - POST
Мне не ясно, как эти спецификации могут позволить значимое кэширование.
Ответ 2
Согласно RFC 2616, раздел 9.5:
"Ответы на метод POST не являются КЕЙСИРОВАТЬ, ЕСЛИ ответ включает соответствующий Cache-Control или Истекает поля заголовка.
Итак, да, вы можете кэшировать ответ запроса POST, но только если он поступает с соответствующими заголовками. В большинстве случаев вы не хотите кэшировать ответ. Но в некоторых случаях - например, если вы не сохраняете какие-либо данные на сервере - это вполне уместно.
Обратите внимание, что многие браузеры, включая текущий Firefox 3.0.10, не будут кэшировать ответ POST независимо от заголовков. IE ведет себя более разумно в этом отношении.
Теперь я хочу прояснить некоторые путаницы в отношении RFC 2616 S. 13.10. Метод POST в URI не "делает недействительным ресурс для кэширования", как некоторые из них заявили здесь. Это делает ранее кэшированную версию этого URI устаревшей, даже если ее заголовки управления кэшем указывают на свежесть более длительной продолжительности.
Ответ 3
В целом:
В принципе POST не является идемпотентной операцией. Поэтому вы не можете использовать его для кеширования. 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 должен аннулировать ресурс для кэширования.
Ответ 4
Если это что-то, что фактически не изменяет данные на вашем сайте, это должен быть запрос GET. Даже если это форма, вы все равно можете установить ее как запрос на получение. Хотя, как и другие, вы можете кэшировать результаты POST, это не будет иметь смысловой смысл, потому что POST по определению изменяет данные.
Ответ 5
Если вы кешируете ответ POST, он должен находиться в направлении веб-приложения. Это означает, что "Ответы на этот метод не являются кэшируемыми, если только ответ не включает соответствующие поля заголовка Cache-Control или Expires".
Можно с уверенностью предположить, что приложение, которое знает, являются ли результаты POST или нет, идемпотент, решает, нужно ли присоединять необходимые и правильные заголовки кеша. Если присутствуют заголовки, предлагающие кэширование, приложение сообщает вам, что POST на самом деле является супер-GET; что использование POST было необходимо только из-за ненужного и неулокального (для использования URI в качестве ключа кэш-памяти) данных, необходимых для выполнения идемпотентной операции.
После этого предположения из кеша может быть отправлено GET.
Приложение, которое не может подключить необходимые и правильные заголовки для разграничения между кэшируемыми и не кэшируемыми ответами POST, не отвечает за любые недопустимые результаты кэширования.
Тем не менее, каждый POST, который попадает в кеш, требует проверки с использованием условных заголовков. Это необходимо для обновления содержимого кеша, чтобы избежать отражения результатов POST в ответах на запросы до истечения срока жизни объекта.
Ответ 6
Конечно, это возможно. Если вы хотите поймать POST-запросы, отправленные на ваш сервер, и кэшировать данные, отправленные обратно, чтобы повторно отправить их позже - нет пота.
Сложная часть приходит в отношении "состояния". Как вы решаете, данные, которые вы хотите отправить обратно пользователю, должны быть одинаковыми? Что делать, если его файлы cookie изменились - это изменит данные, которые вы хотите отправить назад?
Как насчет того, выполнил ли пользователь запрос POST на вашей домашней странице, и с тех пор, как в последний раз он это сделал, другой пользователь отправил ему сообщение (используя некоторую систему внутри вашего сайта). Вам нужно будет определить, и отправьте новую версию своей домашней страницы с уведомлением о сообщении пользователю в следующий раз, когда он загрузит главную страницу. Даже если параметры POST совпадают.
Ответ 7
Марк Ноттингем проанализировал, когда возможно кэшировать ответ POST. Обратите внимание, что последующие запросы, которые хотят использовать кеширование, должны быть запросами GET или HEAD. См. Также httpbis
POST не обрабатываются в представлениях идентифицированного состояния, 99 раз из 100. Однако есть один случай, когда он это делает; когда сервер выходит из его способ сказать, что этот ответ POST представляет собой представление его URI, установив заголовок Content-Location, который совпадает с запросом URI. Когда это происходит, ответ POST похож на ответ GET к тому же URI; его можно кэшировать и повторно использовать, но только для будущего Запросы GET.
Ответ 8
С firefox 27.0 и с httpfox, 19 мая 2014 года, я увидел одну строку из этого: 00: 03: 58.777 0.488 657 (393) POST (Cache) text/html https://users.jackiszhp.info/S4UP
Очевидно, что ответ метода post кэшируется, и он также находится в https. Невероятно!
Ответ 9
POST используется в состоянии Ajax. Возврат кэшированного ответа для POST поражает канал связи и побочные эффекты приема сообщения. Это очень плохо. Это также настоящая боль для отслеживания. Очень рекомендуется против.
Тривиальный пример - это сообщение, которое в качестве побочного эффекта выплачивает вам зарплату в размере 10 000 долларов на текущей неделе. Вы НЕ хотите, чтобы "ОК, все прошло!" страница назад, которая была кэширована на прошлой неделе. Другие, более сложные случаи реального мира приводят к подобному веселью.