Идеологически, в HTTP есть чистые, безопасные запросы
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1) (в
том смысле что не создают побочных эффектов, как то создание/удаление
файлов).
Такими строго являются GET, HEAD и рекомендуется такими делать OPTIONS, TRACE.
Смысл POST в том, чтобы создать/модифицировать ресурс, то есть
идеологически POST нельзя кешировать потому что клиент хочет что-то
изменить. А ему возвращают результат от предыдущего изменения.
Более того, кешировать POST дважды неверно, потому что POST это
единственный "неидемпотентный"
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2)
метод, то есть каждый следущий вызов POST по идее может производить
всё новые и новые побочные эффекты (например, дописывать строчки в
файл). А с кешированием бекенд не получит запроса и не допишет.
Но это всё идеологически. На практике, конечно, часто бывает, что POST
используется там где следовало бы GET или реже бывает (и вот, автор
треда говорит, что именно этот случай), что можно кешировать POST. Всё
зависит от бекенда и чего от запросов ожидается.
2009/5/9 Kostya Alexandrov <koticka@xxxxxxx>:
Извините за ламмерство, а что в этом противоестественного?
Sergey Shepelev wrote:
Вы понимаете, что кешировать посты это противоестественно, да?
2009/5/9 Yura Beznos <nginx@xxxxxxxxxxx>:
proxy_cache - возможно ли кэширование POST запросов?
Предполагается ли сделать это?
(скажем на базе md5 от запроса)