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

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.

Received on Wednesday, 27 April 2011 21:08:07 UTC