- From: Jamie Lokier <jamie@shareable.org>
- Date: Mon, 8 Jun 2009 00:21:06 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote: > On 27/05/2009, at 3:17 AM, Adrien de Croy wrote: > >Wrt POST (or any method). If the response to a POST is marked > >explicitly by the origin server as cachable, why should a subsequent > >POST invalidate that contrary to other Cache-control directives? > >Surely this should only apply if the original method was not POST? > > Because POST changes state on the server; it's a useful pattern to > have POST (or other responses) cached, but invalidated upon a visible > update. But it's unreliable, because requests can go via different proxies. What is the point in mandating that proxies support an unreliable mechanism, which suggests (wrongly) to server authors that they can depend on it, when there are good reliable caching mechanisms in the spec already? -- Jamie
Received on Sunday, 7 June 2009 23:21:43 UTC