W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: #430 / #268 - definition of "public"

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 30 Jan 2013 21:59:53 -0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <86073E4A-C4F7-4033-B5B0-803C570DB4C0@gbiv.com>
To: David Morris <dwm@xpasc.com>
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.

Received on Thursday, 31 January 2013 06:00:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC