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

On 27/04/2011, at 9:03 AM, Poul-Henning Kamp wrote:

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

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. 


> Personally I think such usage would be very inadvisable, bordering
> on looney, but we should still make the text answer the question.

Agreed that it's inadvisable; we can't (and shouldn't) design to cover every possible convoluted case.  However, it is a legitimate case that the Vary header can change over time.


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


I was thinking about that before I got to this part of your message. :)

However, it could be argued that the most recent response rule above applies here as well (and I think it makes sense, in the common -- i.e., non-pathological -- case).

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]).
"""

?

Henrik brought this up in a slightly different way as an issue a while back, btw:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/38

Cheers,

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

Received on Wednesday, 27 April 2011 08:14:34 UTC