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

From: Poul-Henning Kamp <[email-masked]>
Date: Tue, 26 Apr 2011 23:03:27 +0000

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.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Apr 2011 18:14:04 +1000

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

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

> |  presented request to the origin server in a conditional request; see

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/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 27 Apr 2011 08:19:38 +0000

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

Ok, I hadn't connected that requirement to the Vary case, but
it obviously settles the issue.

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Apr 2011 18:29:12 +1000

Reopening #38 to track.

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/38>

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Wed, 27 Apr 2011 21:07:30 +0000

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