Subject: Re: [httpbis] #223: Allowing heuristic caching for new status codes

From: Mark Nottingham <[email-masked]>
Date: Sun, 27 Jan 2013 22:13:09 +0800

I'm in Changai airport right now, and not in any position to tweak.

The overall approach may be workable, but the thing that immediately leaps out at me is the new, magical semantics for public.  No cache behaves like that to my knowledge, and furthermore it's pretty useless; if an origin is going to go to the trouble to mark something public, it can assign an explicit freshness lifetime.

Please hold publication until we work through this; there's no sense in publishing two drafts in as many days. I'll be in Tokyo tomorrow and with any luck we can work through this reasonably quickly; might've worth it todo a quick Skype or FaceTime call. 

I'm genuinely surprised my iPad didn't autocorrect a trademark after FaceTime there. And iPad.

--
Mark Nottingham  http://www.mnot.net/

On 27/01/2013, at 6:50 PM, "httpbis" <[email-masked]> wrote:

> #223: Allowing heuristic caching for new status codes
> -----------------------------+-----------------------------
>  Reporter:  [email-masked]  |      Owner:
>      Type:  design          |     Status:  closed
>  Priority:  normal          |  Milestone:  22
> Component:  p6-cache        |   Severity:  In WG Last Call
> Resolution:  incorporated    |   Keywords:
>    Origin:                  |
> -----------------------------+-----------------------------
> Changes (by [email-masked]):
> 
> * status:  reopened => closed
> * resolution:   => incorporated
> 
> 
> Comment:
> 
> Since the above is mostly editorial (except for the bit about cache-
> control public allowing heuristics), I have gone ahead and committed so
> that we can close out the first WGLC comments. Feel free to tweak it if
> you disagree, or save it for a new issue during the next WGLC.
> 
> -- 
> Ticket URL: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/223#comment:18>
> httpbis <http://tools.ietf.org/wg/httpbis/>
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 27 Jan 2013 16:22:39 -0800

Fine, but I hope you realize that is what RFC2616 defined. Combining cacheability and freshness into one category in p6 lost that distinction, and yes it was an intended design. There is nothing wrong with telling a cache that a response doesn't have a fixed expiration time. That's why found the prior text so disconcerting in p2.

The alternative would be to say that if a response contains public but no max-age, then a cache cannot reuse it without revaluation, which is clearly not what the origin server wants.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 30 Jan 2013 23:34:46 +0900

> The alternative would be to say that if a response contains public but no max-age, then a cache cannot reuse it without revaluation, which is clearly not what the origin server wants.

To catch folks on the list up, Roy has since created:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/430
… and incorporated a proposal.

"""
The "public" response directive indicates that any cache &MAY; store the 
response and reuse it for later requests, even if the response would 
normally be non-cacheable or cacheable only within a non-shared cache. 
(See <xref target="caching.authenticated.responses"/> for additional 
details related to the use of public in response to a request containing 
<x:ref>Authorization</x:ref>.) 
"""

Does anyone have a problem with re-opening the definition of public?

Personally - I'm not against it in principle, but I don't like this specific text. A large part of why we restricted the effect of public in #268 was that this is absurdly vague and open to interpretation; e.g., does it mean that "public" in a response that also has "no-store" can be happily stored?

"…even if the response would normally be non-cacheable or cacheable only within a non-shared cache" needs work. I'm happy to make a specific proposal, given a bit of time, and if folks are amenable to doing so.

I'm re-opening the ticket pending this discussion.

Regards,

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 30 Jan 2013 08:56:02 -0800

> Personally - I'm not against it in principle, but I don't like this specific text. A large part of why we restricted the effect of public in #268 was that this is absurdly vague and open to interpr…

Yes.  Generally speaking, if the origin server puts two mutually
exclusive directives in the same header field, they want the
recipient to apply the most lenient one to which they are fully
compliant (i.e., the same principle we define for extensions).

If the origin server doesn't want that, then it doesn't send public.

I don't see anything vague about it (at least no more vague than the
concept of caching itself).  And keep in mind that this is only a
MAY for caches: they don't have to cache it; they have permission to.

> I'm re-opening the ticket pending this discussion.

That's fine, but we still need to publish 22 today.

....Roy

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 30 Jan 2013 21:27:26 +0000

------ Original Message ------
From: "Roy T. Fielding" <[email-masked]>
>>>  Fine, but I hope you realize that is what RFC2616 defined. Combining 
>>>cacheability and freshness into one category in p6 lost that 
>>>distinction, and yes it was an intended design. There is nothing 
>>>wrong with telling a cache that a response doesn't have a fixed 
>>>expiration time. That's why found the prior text so disconcerting in 
>>>p2.
>>>
>>>  The alternative would be to say that if a response contains public 
>>>but no max-age, then a cache cannot reuse it without revaluation, 
>>>which is clearly not what the origin server wants.
>>
>>  Personally - I'm not against it in principle, but I don't like this 
>>specific text. A large part of why we restricted the effect of public 
>>in #268 was that this is absurdly vague and open to interpretation; 
>>e.g., does it mean that "public" in a response that also has 
>>"no-store" can be happily stored?
>
ok, I think this should be in the spec somewhere.

It's great to have a deterministic way to evaluate precedence of c-c 
directives when they conflict, so we should lead implementors in the 
same direction.

Regards

Adrien

>>  "…even if the response would normally be non-cacheable or cacheable 
>>only within a non-shared cache" needs work. I'm happy to make a 
>>specific proposal, given a bit of time, and if folks are amenable to 
>>doing so.
>>

---

From: David Morris <[email-masked]>
Date: Wed, 30 Jan 2013 13:37:37 -0800 (PST)

> MAY for caches: they don't have to cache it; they have permission to.

Ummm ... that interpretation applied to a conflict in a privacy setting
makes no sense ... a conflcit regarding privacy and/or security must
always be resolved with the most restrictive directive.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 30 Jan 2013 18:06:17 -0800

Neither of which is relevant to this discussion of cache control. It is not the recipients job to second guess the origin server.

....Roy

---

From: Patrick McManus <[email-masked]>
Date: Thu, 31 Jan 2013 11:10:50 +0900

> always be resolved with the most restrictive directive.
+1 - imo if someone put no-mumble on the response that's the strongest
signal due to privacy/security even in a mess of mixed signals.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jan 2013 11:12:26 +0900

> always be resolved with the most restrictive directive.

I agree with David here.  I like determinism, but this particular
choice is the least likeable option of those that are available.  In
resolving an ambiguity, the safest choice is to choose the *least*
liberal caching/sharing option.

That said, we have to respect what actually happens in actual caches.
If this is the current behavior, then let's document that.

---

From: David Morris <[email-masked]>
Date: Wed, 30 Jan 2013 19:12:19 -0800 (PST)

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.
The only sane handling of an error is to minimize possible damage. Damage
from caching something which shouldn't be cached is that private
content will be revealed to an unauthorized recipient. Caching is
always optional, so not caching something the server thought could
be cached is at most a performance issue. 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?

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 31 Jan 2013 03:41:17 +0000

In this case we're talking about a response with public and no-store

I've always felt relying on unknown caches to obey C-C directives as 
part of your security model is at best extremely weak.

If as a website operator you really have a problem with the possibility 
of some other user getting the content you generated for someone else 
due to some bad intermediary cache, then maybe you should be ensuring 
the URIs are different, or that the content is somehow secured.

>From testing we've done here, over 80% of C-C response headers are used 
to suppress caching.  Often in as many ways as the website author can 
think of.

To derive any real value to a customer out of running a cache, you 
basically have to flagrantly diregard and even downright overrule the 
C-C directives.  Otherwise it's not worth the cost (mainly extra request 
latency).

Very few sites actually try to promote it (e.g. Google maps).  Even 
heuristic caching is not quite enough, as there commonly is no 
Last-Modified header (about 50% of requests with no Expiry or max-age or 
s-maxage have no Last-Modified either).

IME most sites specify cache-suppressive C-C response headers in cases 
they don't really need to.  This results in clients having to maintain 
maps of sites that they ignore C-C from.

Anyway I digress.  It would be nice if there were some way to attempt to 
start to clean this up, and defining precedence of operators would be a 
big help.

Adrien

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 30 Jan 2013 21:59:53 -0800

> 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
> 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
> 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

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