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

From: HTTP issue updates <[email-masked]>
Date: Sun, 01 Nov 2015 21:08:55 -0800

My suggestion is to have OR semantics for key-values of the same type, but AND for key-values of different types.  That would solve most of the sorts of problem that Ilya identified without a need to create operators, which complicate the grammar and implementation considerably.

So `s=a;s=b` means "a" or "b", but `s=c;m=d` means "c" and "d".

cc @igrigorik

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 11 Nov 2015 16:02:54 -0800

@igrigorik please also have a look at discussion in #108. We need to figure out whether this hits the use cases, would appreciate your views.

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

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 15 Nov 2015 16:12:37 -0800

Hey @igrigorik - the problem with defining an operator like that is that it pushes a LOT of complexity into the algorithm and its implementation. Right now, each parameter results in a string that can be written into the secondary cache key, so its processing is very simple. 

It's also not clear how some parameters would combine; e.g., what does `partition=20:30 and match=foo` mean? 

It would really help if we had some **concrete** examples of what people would want to do with OR.

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 16 Nov 2015 12:15:09 -0800

> It's also not clear how some parameters would combine; e.g., what does `partition=20:30` and `match=foo` mean?

If I understand the current semantics correctly, the above would yield <20, <20+foo, 20-30, 20-30+foo, >30, 30+foo buckets? Presumably, adding another match value in there would further extend the number of buckets by another factor of 2?

> It would really help if we had some concrete examples of what people would want to do with OR.

1. My original example of User-Agent matching is one: https://github.com/mnot/I-D/issues/21#issue-15143707. 
1. I can imagine Cookie use-cases with very similar semantics, where you can have multiple different values that you'd want to resolve to the same cache entry?

Perhaps (1) can be addressed by looking at "Mobi" and other substrings.. there are edge cases here across all the various shipped browsers, but maybe that's OK. For (2), arguably the site controls the cookie so they can establish a stable key and use that.

For existing Client-Hints what we have already is probably enough: you'd use partition against `Width` hint to account for the DPR+resource width variants; or partition against `DPR` or `Viewport-Width`. When combined with Save-Data match you'd then double the number of buckets... there is no way to indicate that some buckets should be combined, but maybe that's ok? If anything that's a feature that could be added later?

@yoavweiss can you think of any edge case here for CH?

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 16 Nov 2015 22:02:04 -0800

> I'm starting to suspect that this is primarily about substr. 

*nod*. I think it makes sense to scope this discussion substr in particular.

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 18 Nov 2015 17:35:10 -0800

OK. If that's the case, does something like

> `Key: User-Agent;substr=mobi|android`

do the trick?

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

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 20 Nov 2015 16:29:08 -0800

Yeah.. Except, what if I have a `|` in my substring? :P

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

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 20 Nov 2015 17:10:06 -0800

Well, we can either escape it, or we can say that we don't think it's likely that the headers that Key will be targeting will contain that character.

I like the latter; IME developers often don't bother to implement escaping in performance-critical code.

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 23 Nov 2015 15:46:57 -0800

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

would create four potential cache entries:

1. `DPR` < 1.2, `Save-Data` = 1
2. `DPR` < 1.2, `Save-Data` != 1
3. `DPR` > 1.2, `Save-Data` = 1
4. `DPR` > 1.2, `Save-Data` != 1

It sounds like you want to collapse 1,2 and 3 into one cache entry, correct?

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 25 Nov 2015 00:24:45 -0800

That is correct

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 30 Nov 2015 10:52:23 -0800

Hmm, not sure if this is a deal breaker, but it's not a great outcome.. In effect, we're discouraging folks from reporting granular hints. With CH our goal is to get enable the UA/app to advertise any and all relevant hints to the server, each via its own header. However, with the model we have here, each and every key expands the cache space, with no ability to collapse it -- this, in effect, discourages use and deployment of new hints.

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