Subject: Re: httpbis-p6-cache-14, and vary headers

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 May 2011 10:27:21 +1000

Hi Jon,

See the followup discussion.

Cheers,

On 28/04/2011, at 7:07 AM, Moore, Jonathan (CIM) wrote:

> Letting the cache decide feels right to me; each of the origin responses is saying "this is an appropriate cacheable response for requests meeting such-and-such Vary criteria", so I think returning any or none of them would be correct as far as the semantic transparency described by the origin headers.
> 
> Jon
> ________________________________________
> From: [email-masked] [[email-masked]] on behalf of Poul-Henning Kamp [[email-masked]]
> Sent: Tuesday, April 26, 2011 7:03 PM
> To: [email-masked]
> Subject: httpbis-p6-cache-14, and vary headers
> 
> This may qualify for an official action item:
> 
> 
> Presently the text says nothing about how to resolve which of multiple
> different Vary-matching objects a cache should return.
> 
> ie:  Imagine a cache contains:
> 
> Obj1: URI = /,  Foo: foo1,            Vary: foo
> Obj2: URI = /,             Bar: bar1, Vary: bar
> Obj3: URI = /,  Foo: foo1, Bar: bar1, Vary: foo, bar
> Obj4: URI = /,  Foo: foo1, Bar: bar1, Vary: bar, foo
> 
> if a request comes in with:
> 
>        URI= /, Foo: foo1, Bar: bar1
> 
> All four objects qualify, which one should be delivered ?
> 
> Personally I think such usage would be very inadvisable, bordering
> on looney, but we should still make the text answer the question.
> 
> We can do this several ways:
> 
> A) Mandating that all objects of a given URI has the same Vary: header.
>   This will be a significant semantic tightening of the spec and possibly
>   too draconian for the WG charter.
> 
> Or we can take the hard but, since nobody does anything like this in
> real life, pointless mental exercise:
> 
> B) Try to formulate a coherent and unmistakable policy which caches
>   should use to resolve such conflicts.  This may also run into the
>   limited reach of the WG-charter.
> 
> Alternatively we can punt and:
> 
> C) Make it absolutely clear that it is entirely up to the cache
>   to pick which object to deliver in this case.
> 
> 
> My proposal is that pick C) by changing the text around the second
> to last paragraph in 2.7:
> 
> |  The stored response with matching selecting header fields is known as
> |  the selected response.
> 
> +  If multiple selected reponses are available, the cache picks any
> +  one of them according to its own criteria.  This situation is best
> +  avoided by ensuring that all objects with a given URI has the same
> +  Vary: header.
> 
> |  If no selected response is available, the cache MAY forward the
> |  presented request to the origin server in a conditional request; see
> |  Section 2.4.
> 
> 
> 
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> [email-masked]         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> 
> 

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 May 2011 13:49:09 +1000

I haven't heard any objections to the proposal below; incorporating in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1289>.

On 27/04/2011, at 6:29 PM, Mark Nottingham wrote:

> Reopening #38 to track.
> 
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/38>
> 
> 
> On 27/04/2011, at 6:19 PM, Poul-Henning Kamp wrote:
> 
>> In message <[email-masked]>, Mark Nottingham wri
>> tes:
>> 
>>> Vary isn't ordering-dependent, so Obj3 and Obj4 are equivalent, and the 
>>> latest one should be used as per this requirement in p6 2.2:
>>> 
>>> A cache MUST use the most recent response (as determined by the Date
>>> header field) when more than one suitable response is stored. 
>> 
>> Ok, I hadn't connected that requirement to the Vary case, but
>> it obviously settles the issue.
>> 
>>> What about something like
>>> 
>>> """
>>> If multiple selected responses are available, the most recent response 
>>> (as determined by the Date header field) is used (see [section 2.2]).
>>> """
>> 
>> Works for me.
>> 
>> --