可以在HTTP中缓存POST方法吗？

使用非常简单的缓存语义：如果参数相同（当然URL也是相同的），那么它就是成功的。可能吗？推荐？

第9.5节（POST）中的相应内容允许缓存对POST消息的响应，如果您使用适当的标题

对此方法的响应不可缓存，除非响应 包括适当的缓存控制或Expires标头字段。然而， 303（参见其他）响应可用于指示用户代理 检索可缓存的资源

请注意，相同的RFC在第13节（HTTP缓存）中明确指出，缓存必须在POST请求后使相应的实体无效

某些HTTP方法必须导致 缓存以使实体无效。这是 该公司所指的实体 请求URI，或按位置或 内容位置标题（如果存在）。 这些方法是：

  - PUT
  - DELETE
  - POST

我不清楚这些规范如何允许有意义的缓存

这也在（第4.3.3节）中得到反映和进一步澄清，该节淘汰了RFC 2616

对POST请求的响应只有在包含
明确的新鲜度信息（见[RFC7234]第4.2.1节）。
然而，后缓存并没有得到广泛的实现。 对于源服务器希望客户端能够 缓存POST结果的方式可供以后的用户重复使用 获取时，源服务器可能会发送一个200（OK）响应，其中包含 结果和具有相同值的内容位置标题字段 作为邮政的有效请求URI（第3.1.4.2节）

---

根据这一点，缓存帖子的结果（如果服务器指示此功能）随后可以作为相同URI的GET请求的结果使用。

如果它实际上没有更改站点上的数据，则应该是GET请求。即使是表单，也可以将其设置为get请求。正如其他人指出的那样，虽然可以缓存帖子的结果，但这在语义上没有意义，因为根据定义，帖子正在更改数据

总体情况：

基本上。因此，不能将其用于缓存。GET应该是一个幂等运算，因此它通常用于缓存

请参见第9.1节

除GET方法的语义外：

POST方法本身在语义上意味着向资源发布某些内容。无法缓存POST，因为如果您执行一次、两次或三次操作，则每次都会更改服务器的资源。每个请求都很重要，应该传递到服务器

PUT方法本身在语义上意味着放置或创建资源。这是一个幂等操作，但不会用于缓存，因为在此期间可能发生了删除

DELETE方法本身在语义上意味着删除资源。这是一个幂等操作，但不会用于缓存，因为在此期间可能发生PUT

关于客户端缓存：

web浏览器将始终转发您的请求，即使它有来自上一次POST操作的响应。例如，你可以每隔几天用gmail发送电子邮件。它们可能是相同的主题和主体，但两封电子邮件都应该发送

关于代理缓存：

将您的消息转发到服务器的代理HTTP服务器除了GET或HEAD请求外，永远不会缓存任何内容

关于服务器缓存：

默认情况下，服务器不会通过检查缓存自动处理POST请求。当然，POST请求可以发送到您的应用程序或外接程序，并且您可以拥有自己的缓存，在参数相同时从中读取

使资源无效：

---

检查显示POST方法应使用于缓存的资源无效

根据RFC 2616第9.5节：

“对POST方法的响应不正确 可缓存，除非响应 包括适当的缓存控制或 过期标题字段。“

所以，是的，您可以缓存POST请求响应，但前提是它带有适当的头。在大多数情况下，您不希望缓存响应。但在某些情况下（例如，如果您没有在服务器上保存任何数据），这是完全合适的

注意，但是许多浏览器，包括当前的Firefox 3.0.10，无论标题如何，都不会缓存POST响应。IE在这方面表现得更聪明

---

现在，我想澄清一下关于RFC 2616 S.13.10的一些困惑。URI上的POST方法不会像一些人在这里所说的那样“使缓存资源无效”。它会使该URI的先前缓存版本变得陈旧，即使其缓存控制头指示了较长持续时间的新鲜度。

POST用于有状态Ajax。返回POST的缓存响应会破坏通信通道和接收消息的副作用。这是非常非常糟糕的。追查起来也很痛苦。强烈建议反对

---

一个简单的例子是一条信息，作为副作用，它会在本周支付你10000美元的薪水。您不想返回上周缓存的“OK，它通过了！”页面。其他更复杂的现实世界案例也会引起类似的欢笑。

2014年5月19日，firefox 27.0和httpfox，我看到了这样一句话： 00:03:58.777 0.488 657（393）POST（缓存）文本/html

显然，post方法的响应是缓存的，并且也是https格式的。

---

难以置信

马克·诺丁汉（MarkNottingham）分析了何时可以缓存帖子的响应。请注意，要利用缓存的后续请求必须是GET或HEAD请求。另见

帖子不处理已标识状态的表示

13.10 Invalidation After Updates or Deletions

..

Some HTTP methods MUST cause a cache to invalidate an entity. This is
either the entity referred to by the Request-URI, or by the Location
or Content-Location headers (if present). These methods are:
  - PUT
  - DELETE
  - POST

9.5 POST

..

Responses to this method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields. However,
the 303 (See Other) response can be used to direct the user agent to
retrieve a cacheable resource.

13.11 Write-Through Mandatory

..

All methods that might be expected to cause modifications to the
origin server's resources MUST be written through to the origin
server. This currently includes all methods except for GET and HEAD.
A cache MUST NOT reply to such a request from a client before having
transmitted the request to the inbound server, and having received a
corresponding response from the inbound server. This does not prevent
a proxy cache from sending a 100 (Continue) response before the
inbound server has sent its final reply.