W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

httpbis-p6-cache-14, and vary headers

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Tue, 26 Apr 2011 23:03:27 +0000
To: ietf-http-wg@w3.org
Message-ID: <46035.1303859007@critter.freebsd.dk>

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 Tuesday, 26 April 2011 23:03:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:40 GMT