Subject: p6: Returning the freshest response

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Mar 2013 14:10:11 +1100

p6 currently says;

> When more than one suitable response is stored, a cache must use the most recent response (as determined by the Date header field).

https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#constructing.responses.from.caches

... which was sourced pretty directly from 2616:

>  A correct cache MUST respond to a request with the most up-to-date response held by the cache that is appropriate to the request

Interpreted strictly*, this means that if a cache has two fresh representations:

  Content-Type: image/jpeg
  Date: Thu, 14 Feb 2013 03:08:09 GMT

  Content-Type: image/png
  Date: Thu, 14 Feb 2013 03:08:08 GMT

and it gets a request with:

  Accept: image/jpeg;q=0.1, image/png;q=1.0

then it'll return the JPEG because it's fresher, even though the client clearly prefers the PNG.

However that's not the whole story. To get to those multiple responses, the cache goes through the process of winnowing down the potentially matching stored responses, using the process described in <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#caching.negotiated.responses>.

That section says:

> If multiple selected responses are available, the most recent response (as determined by the Date header field) is used; see Section 4.

which I put into p6 based upon the above.

So, I'm wondering if we should change that to something like:

"""
If multiple selected responses are available, the cache will need to choose one to use. If a selecting header has a known mechanism for doing so (e.g., qvalues on Accept and similar request headers), it MAY be used to select one; otherwise, the most recent response (as determined by the Date header field) is used, as per Section 4.
"""

Thoughts?

* "appropriately" doesn't give us enough leeway here on its own; see the context.

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

---

From: Eitan Adler <[email-masked]>
Date: Fri, 29 Mar 2013 00:02:26 -0400

> > When more than one suitable response is stored, a cache must use the most recent response (as determined by the Date header field).

Why not word this something like:

When more than one suitable otherwise identical responses are stored, a
cache must use the most recent response (as determined by the Date
header field).  The cache may choose whether to honor other priority
information, such as qvalues on Accept, above the recency of the date.

This keeps the requirement to honor the date when the cache has two
entries and no other means to distinguish between them.

--
Eitan Adler

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Mar 2013 11:24:42 -0400

> If multiple selected responses are available, the cache will need to choose one to use. If a selecting header has a known mechanism for doing so (e.g., qvalues on Accept and similar request headers…

Again, I am the farthest thing from a HTTP cache expert but here are my 
thoughts based on my numerous readings of the current p6 draft in an 
attempt to educate myself.  Forgive me if I have waded too far into the 
deep end.

It seems to me that the rules in Sections 4 and 4.3 center around the 
fact that a cached response resulting from proactive content negotiation 
will include a Vary header, even though the presence of such a header in 
the server response is a MAY per 
https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#proactive.negotiation.

So the (my) question is, what can/should a cache do with multiple stored 
responses in the absence of any Vary headers, as in your example above?  
Can the cache use proactive content negotiation headers provided in the 
request to select the stored response that the client would prefer?  Or 
should the cache not select a response and punt it to the origin server 
per Section 4.2?

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Mar 2013 08:47:43 -0700

> If multiple selected responses are available, the cache will need to choose one to use. If a selecting header has a known mechanism for doing so (e.g., qvalues on Accept and similar request headers…

This seems good.  The "it" in "it MAY be used to select one" is
perhaps ambiguous, but I don't see how to fix it without making it
even harder to parse :)

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Mar 2013 08:48:45 -0700

On 29 March 2013 08:24, Ken Murchison <[email-masked]> wrote:
> responses in the absence of any Vary headers, as in your example above?  Can
> the cache use proactive content negotiation headers provided in the request
> to select the stored response that the client would prefer?  Or should the
> cache not select a response and punt it to the origin server per Section
> 4.2?

An origin server is required to include a Vary header if conneg is
possible, even if conneg isn't used.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Mar 2013 12:02:36 -0400

> possible, even if conneg isn't used.
Hi Martin,

The current language in 
https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#proactive.negotiation 
(MAY) and 
https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#header.vary 
(SHOULD)
don't seem to make it a requirement.  However, the SHOULD certainly 
suggests best practice.

That notwithstanding, unless Mark's example omitted the Vary headers for 
brevity, my question still stands.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Mar 2013 09:39:20 -0700

On 29 March 2013 09:02, Ken Murchison <[email-masked]> wrote:
> don't seem to make it a requirement.  However, the SHOULD certainly suggests
> best practice.

I think that this might trigger a review comment:

The MAY is spurious, no 2119 language is needed here: the text need
only highlight that it is possible (as opposed to permissible) for a
Vary header to be present.

The SHOULD is qualified sufficiently that I believe that a MUST is
more appropriate.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 30 Mar 2013 09:08:14 +1100

On 30/03/2013, at 3:02 AM, Ken Murchison <[email-masked]> wrote:

> That notwithstanding, unless Mark's example omitted the Vary headers for brevity, my question still stands.

It did; sorry for the confusion.

Without Vary, the server hasn't given any information about how to select a response, so the only thing a cache can do is fall back to using the most recent.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 30 Mar 2013 09:11:38 +1100

> Vary header to be present.

There seem to be a lot of MAYs in p2; some of them are mostly harmless, but this one seems to be actively misleading. Roy, Julian?

The requirement is of the form "SHOULD... unless...", with the clause:

> , unless the variance cannot be crossed or the origin server has been deliberately configured to prevent cache transparency.

so I think this one is OK.

Cheers,

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Mar 2013 15:32:14 -0700

> so I think this one is OK.

I'm not familiar with the "SHOULD...unless" construct.
"MUST...unless" is better typically, unless there are other,
unspecified reasons that this directive can be ignored.

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 31 Mar 2013 13:30:13 +1300

> perhaps ambiguous, but I don't see how to fix it without making it

Perhapse this is a bit better?

"

If multiple selected responses are available, the cache will need to choose one to use. When a selecting header has a known mechanism for doing so (e.g., qvalues on Accept and similar request headers), that mechanism SHOULD be used to eliminate unwanted responses; of the remainder, the most recent response (as determined by the Date header field) is used, as per Section 4.

"

Making it clear that Date mechanism still applies, but only after the 
negotiation filtering has been done. AFAIK that is how it always gets 
done in practice anyway.

Amos

---

From: Eitan Adler <[email-masked]>
Date: Mon, 1 Apr 2013 00:53:06 -0400

On 30 March 2013 20:30, Amos Jeffries <[email-masked]> wrote:
>>> If multiple selected responses are available, the cache will need to
>>> choose one to use. If a selecting header has a known mechanism for doing so
>>> (e.g., qvalues on Accept and similar request headers), it MAY be used to
>>> select one; otherwise, the most recent response (as determined by the Date
>>> header field) is used, as per Section 4.
>>> """
>>
> If multiple selected responses are available, the cache will need to choose
> one to use. When a selecting header has a known mechanism for doing so
> (e.g., qvalues on Accept and similar request headers), that mechanism SHOULD
> be used to eliminate unwanted responses; of the remainder, the most recent
> response (as determined by the Date header field) is used, as per Section 4.

I like this wording the best of the options in this thread so far.

-- 
Eitan Adler