hit-for-pass vs. hit-for-miss

[Nils Goroll]

(quick brain dump before I need to rush out)

Geoff discovered this interesting consequence of a recent important change of
phk and we just spent an hour to discuss this:

before commit 9f272127c6fba76e6758d7ab7ba6527d9aad98b0, a hit-for-pass object
lead to a pass, not it's a miss. IIUC the discussions we had on a trip to
Amsterdam, phks main motivation was to eliminate the potentially deadly effect
unintentionally created hfps had on cache efficiency: No matter what, for the
lifetime of the hfp, all requests hitting that object became passes.

so, in short

- previously: an uncacheable response wins and sticks for its ttl
- now:        an cacheable response wins and sticks for its ttl

or eben shorter:

- previously:	hit-for-pass
- now:		hit-for-miss

>From the perspective of a cache, the "now" case seems clearly favorable, but now
Geoff has discovered that the reverse is true for a case which is important to
one of our projects:

- varnish is running in "do how the backend says" mode
- backend devs know when to make responses uncacheable
- a huge (600MB) backend response is uncacheable, but client-validatable

so this is the case for the previous semantics:

- 1st request creates the hfp
- 2nd request from client carries INM
  - gets passed with INM
  - 304 from backend goes to client

What we have now is:

- 1st request creates the hfm (hit-for-miss)
- 2nd request is a miss
  - INM gets removed
  - backend sends 600MB unnecessarily

We've thought about a couple of options which I want to write down before they
expire from my cache:

* decide in vcl_hit

   sub vcl_hit {
	if (obj.uncacheable) {
		if (obj.http.Criterium) {
			return (miss);
		} else {
			return (pass);
		}
	   }
  }

* Do not strip INM/IMS for miss and have a bereq property if it was a misspass

  - core code keeps INM/IMS
  - builtin.vcl strips them in vcl_miss
  - can check for hitpass in vcl_miss
  - any 304 backend response forced as uncacheable
    - interesting detail: can it still create a hfp object ?

  BUT: how would we know in vcl_miss if we see
  *client* inm/ims or varnish-generated inm/ims ?

So at this point I only see the YAS option.

Nils