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

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: ietf-http-wg-request@w3.org [ietf-http-wg-request@w3.org] on behalf of Poul-Henning Kamp [phk@phk.freebsd.dk]
> Sent: Tuesday, April 26, 2011 7:03 PM
> To: ietf-http-wg@w3.org
> 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
> phk@FreeBSD.ORG         | 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/

Received on Wednesday, 4 May 2011 00:27:48 UTC