ну хорошо. а что делать если в запрос идет большое количество параметров?
или как параметр нужно передать например xml файл и т.п.
Не расстраивайтесь, предыдещий автор не совсем прав. В RFC написано, что
"если очень хочется, то можно", а именно "Responses to this method are
not cacheable, unless the response includes appropriate Cache-Control or
Expires header fields."
rfc это хорошо, но "жизненные реали" не всегда подходят под rfc.
например до сих пор нет двунаправленного соединения over http и т.п.
на практике большой разницы между гет и пост нет, в том числе
большинство сервлетных движков
отлично обрабатывают и гет и пост совершенно одиниково.
Sergey Shepelev wrote:
Такими строго являются 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 от запроса)
