Subject: Re: [http-extensions] Support "Or" operator (#104)

From: HTTP issue updates <[email-masked]>
Date: Sun, 21 Feb 2016 14:43:31 -0800

Thinking about this a bit more. We could introduce limited operators. E.g., we could specify when another header's portion of the key should be discarded.

Taking the example above and adding the calculated secondary cache key:

`Key: DPR;partition=1.2, Save-Data;match=1`

* DPR < 1.2, Save-Data = 1	`0:1`
* DPR < 1.2, Save-Data != 1	`0:0`
* DPR > 1.2, Save-Data = 1	`1:1`
* DPR > 1.2, Save-Data != 1	`1:0`

We could at least make 1 and three equivalent like this:

`Key: DPR;partition=1.2, Save-Data;match=1;discard=1:DPR`

* DPR < 1.2, Save-Data = 1	`:1`
* DPR < 1.2, Save-Data != 1	`0:0`
* DPR > 1.2, Save-Data = 1	`:1`
* DPR > 1.2, Save-Data != 1	`1:0`

because `discard=1:DPR` tells us to discard the `DPR` portion of the key if `Save-Data`'s post-processing value is `1`.

This would need some massaging, of course, and it wouldn't be able to express all of the interdependencies between headers (notice that the second case is still a distinct cache entry). However, it would help avoid a complete combinetric cache explosion.

I'm torn as to whether this is a good idea; Ilya could be right that in complex situations, we'll just fiddle request header semantics and/or synthesise new headers with ServiceWorker (although it'd be a great pity to use SW just for that, I think). 

WDYT?

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/104#issuecomment-186936535

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 21 Feb 2016 23:20:20 -0800

> DPR < 1.2, Save-Data = 1 :1
> DPR < 1.2, Save-Data != 1 0:0
> DPR > 1.2, Save-Data = 1 :1
> DPR > 1.2, Save-Data != 1 1:0

That's better than before, but I suspect that for this use case the desired outcome is:
* DPR < 1.2, Save-Data = 1: 1x
* DPR < 1.2, Save-Data != 1: 1x
* DPR > 1.2, Save-Data = 1: 1x
* DPR > 1.2, Save-Data != 1: 2x

So, adding `discard` improves things and reduces unnecessary cache explosion, but doesn't eliminate it.

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/104#issuecomment-187049866

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 22 Feb 2016 00:47:43 -0800

Yep. I don't see a reasonable way to get to that without starting over from scratch, and making it significantly more complex. Happy if someone else can, though.

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/104#issuecomment-187075898

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 22 Feb 2016 04:00:34 -0800

At least for this particular scenario, the browser is not likely to change DPR values, so the cache verbosity is likely to be at the cache servers. 

Cache servers could avoid storing multiple instances of the same resource by having a 2-step lookup, where lookup-name=>content-hash=>resource-contents so that multiple lookup-names can lead to the same resource-contents if they have the same content-hash.

So, if this is the only example we can come up with, maybe we should punt this issue until we see more usage in the wild and/or come up with more use cases?

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/104#issuecomment-187143647