使用非常简单的缓存语义:如果参数相同(当然URL相同),那么它就是一个命中.那可能吗？推荐的？
如果使用适当的头,则9.5节(POST)中相应的RFC 2616允许缓存对POST消息的响应.
除非响应包含适当的Cache-Control或Expires头字段,否则对此方法的响应不可缓存.但是,303(请参阅其他)响应可用于指示用户代理检索可缓存资源.
请注意,相同的RFC在第13节(在HTTP中缓存)中明确指出缓存必须在POST 请求后使相应的实体无效.
某些HTTP方法必须导致缓存使实体无效.这可以是Request-URI引用的实体,也可以是Location或Content-Location头(如果存在).这些方法是:
- PUT - DELETE - POST
我不清楚这些规范如何允许有意义的缓存.
根据RFC 2616第9.5节:
"对POST方法的响应不可缓存,除非响应包含适当的Cache-Control或Expires头字段."
所以,是的,你可以缓存POST请求响应,但只有当它到达时才有适当的头.在大多数情况下,您不希望缓存响应.但在某些情况下 - 例如,如果您没有在服务器上保存任何数据 - 这是完全合适的.
请注意,然而,无论标头如何,许多浏览器(包括当前的Firefox 3.0.10)都不会缓存POST响应.在这方面,IE表现得更聪明.
现在,我想澄清一些关于RFC 2616 S. 13.10的混淆.对于URI的POST方法不会"使用于缓存的资源无效",正如一些人在此处所述.它使该URI的先前缓存版本过时,即使其缓存控制头指示较长持续时间的新鲜度.
总体:
基本上POST不是幂等操作.所以你不能用它来缓存.GET应该是幂等操作,因此它通常用于缓存.
请参阅HTTP 1.1 RFC 2616 S. 9.1的9.1节.
除了GET方法的语义之外:
POST方法本身在语义上意味着将某些东西发布到资源.POST无法缓存,因为如果你做了一次vs两次而不是三次,那么你每次都在改变服务器的资源.每个请求都很重要,应该发送到服务器.
PUT方法本身在语义上意味着放置或创建资源.它是一个幂等操作,但它不会用于缓存,因为在此期间可能发生了DELETE.
DELETE方法本身在语义上意味着删除资源.它是幂等操作,但它不会用于缓存,因为PUT可能同时发生.
关于客户端缓存:
即使Web浏览器具有先前POST操作的响应,它也将始终转发您的请求.例如,您可以在几天内发送带有Gmail的电子邮件.它们可能是相同的主题和正文,但两封电子邮件都应该发送.
关于代理缓存:
将消息转发到服务器的代理HTTP服务器永远不会缓存除GET或HEAD请求之外的任何内容.
关于服务器缓存:
默认情况下,服务器不会通过检查其缓存自动处理POST请求.但是当然可以将POST请求发送到您的应用程序或加载项,并且您可以拥有自己的缓存,这些缓存可以在参数相同时读取.
使资源无效:
检查HTTP 1.1 RFC 2616 S. 13.10表明POST方法应该使资源无效以进行缓存.
如果您确实缓存了POST响应,则它必须位于Web应用程序的方向上.这就是"除非响应包含适当的Cache-Control或Expires头字段,否则对此方法的响应不可缓存."
可以安全地假设知道POST的结果是否是幂等的应用程序决定是否附加必要和适当的缓存控制头.如果存在允许缓存的标题,则应用程序会告诉您POST实际上是超级GET; 因为执行幂等操作所必需的数据(对于使用URI作为缓存键)所需的数量,才需要使用POST.
在这个假设下,可以从缓存中提供GET.
无法附加必要且正确的标头以区分可缓存和不可缓存的POST响应的应用程序对于任何无效的缓存结果都是错误的.
也就是说,每个命中缓存的POST都需要使用条件头进行验证.这是为了刷新缓存内容以避免在对象的生命周期到期之前不会在请求的响应中反映POST的结果.
京公网安备 11010802040832号 | 京ICP备19059560号-6 