On Tue, Jun 30, 2015 at 12:28 PM, Mike West <mkwst@google.com> wrote: > On Tue, Jun 30, 2015 at 9:24 PM, Richard Barnes <rbarnes@mozilla.com> > wrote: >> >> Looking at the above discussion, it looks like Ilya's just wrong, in >> particular in this assertion: >> >> """ >> Prefer: x,y,z" forces "x,y,z" to become part of the cache key, evne if x >> and y have no business of being part of the cache key." >> """ >> >> We've already crossed that bridge -- there are some "Prefer" values that >> you want to be part of the cache key (return=minimal) and some that you >> don't (wait). So caches already need to either take into account the >> contents of Prefer or accept the penalty of having irrelevant stuff in the >> key. Note that for in-browser caches, the list of Prefer values is >> probably going to be static anyway, so this whole discussion is moot. >> >> Given that, ISTM that "Prefer: upgrade-insecure-requests" is the right >> option here, or your favorite aesthetic variant thereof. >> > > +Ilya, who I would dearly love to be wrong, as `Prefer` seems like the > right thing to do. > My point here was that "Vary" is a blunt instrument. When you tell the cache to Vary on "Prefer"... per spec, the cache simply takes the full value of said header and makes it part of its cache key. As such, if you have multiple values in the same header, then you have unnecessary fragmentation; this is not an issue if you have a dedicated header per value. To say that "caches must account for this" when the spec (and existing implementations) say precisely otherwise.. is not a great route. On a related note, this is why I keep pushing for Key: https://tools.ietf.org/html/draft-fielding-http-key-02 On Wed, Jul 1, 2015 at 9:47 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > `Prefer: https` seems about right; we should not over-optimize this. +1 for separate header. This resolves the Vary issue. ig
Received on Tuesday, 7 July 2015 21:27:22 UTC