- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 30 Jan 2013 21:59:53 -0800
- To: David Morris <dwm@xpasc.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Jan 30, 2013, at 7:12 PM, David Morris wrote: > On Wed, 30 Jan 2013, Roy T. Fielding wrote: > >> Neither of which is relevant to this discussion of cache control. It is >> not the recipients job to second guess the origin server. > > In this case, the origin server didn't tell the recipient what to do. Yes it did. > The only sane handling of an error is to minimize possible damage. There is no error (nor damage) in caching according to the origin server's decree. > Damage > from caching something which shouldn't be cached is that private > content will be revealed to an unauthorized recipient. No, it will not. Caching has nothing to do with private content. It even says that in the same section. Cache-control is about guiding caches, and if the origin server wants to guide a cache in a certain direction then that's the direction given. > Caching is > always optional, so not caching something the server thought could > be cached is at most a performance issue. Unless it is necessary to sustain services, as it almost always is. > We've expended an enormous > amount of effort with all the rules and support around insuring > correct behavior around caching. Why would be specify conflict > resolution which assumes more relaxed rules? Because that is how the protocol was designed to work in 1995 and that is how it is still designed to work today. Caching is a tradeoff of consistency for availability and performance. The only reason an origin server will ever add public (or private, for that matter) to a response is to encourage caching by compliant caches. There are many reasons an origin server might want to send two signals in the same message, the primary one being that they are aware of a buggy recipient that will ignore the public and obey the no-cache. Hence, they are deliberately using the two to selectively enable caching by recipients that don't behave in the same way. Regardless, we are talking about core semantics, not some editorial choice of how to describe the protocol. This is part of the Cache-Control definition, it was intentional, and cannot be changed without changing the major version. ....Roy
Received on Thursday, 31 January 2013 06:00:21 UTC