Subject: Re: p6: Returning the freshest response

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Apr 2013 08:55:09 -0700

Rather than "eliminate unwanted responses", because in Mark's example,
both were acceptable with different qvalues, how about "select
preferred responses".

On 30 March 2013 17:30, Amos Jeffries <[email-masked]> wrote:
> On 30/03/2013 4:47 a.m., Martin Thomson wrote:
>>
>> On 28 March 2013 20:10, Mark Nottingham <[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.
>>> """
>>
>> 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 :)
>>
>
> 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: Mark Nottingham <[email-masked]>
Date: Wed, 3 Apr 2013 15:32:39 +1100

On 31/03/2013, at 11:30 AM, Amos Jeffries <[email-masked]> wrote:

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

I'm OK with your intent, but upgrading the MAY to a SHOULD is going to make implementations non-conformant. 

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

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 03 Apr 2013 22:27:08 +1300

> I'm OK with your intent, but upgrading the MAY to a SHOULD is going to make implementations non-conformant.

How? and which ones?

I would think upgrading it to MUST would make things non-conformant but 
SHOULD is not absolute.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Apr 2013 22:46:51 +1100

On 03/04/2013, at 8:27 PM, Amos Jeffries <[email-masked]> wrote:

> I would think upgrading it to MUST would make things non-conformant but SHOULD is not absolute.

That's not what SHOULD means. A SHOULD is still a requirement; it's just that there are situations where there's ample justification for violating it.

Also, with a very few exceptions, RFC2119 requirements are used to improve interoperability. This isn't an interoperability requirement.

We can't impose a SHOULD -- especially on something like this, when many implementations are likely to violate it today -- just because we really want something to happen. 

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 22 Apr 2013 14:03:12 +1000

Now:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/453

On 29/03/2013, at 2:10 PM, Mark Nottingham <[email-masked]> wrote:

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