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. > Adding header bloat to HTTP/1.1 seems like a feature, not a bug :) >>> >> >> I am totally going to use exactly this claim if/when I ever get around to >> rekindling the origin cookie discussion, where I'm pretty sure you argued >> exactly the opposite. :) >> > > Conveniently, I have no recollection of that discussion! > It might have been Martin, now that I think of it. Or Mark. No matter, it's a good argument, and I agree with it! > For h2 users, there should be no need to use this thing >>> >> >> Why not? I suspect mixed content will still exist for folks who migrate >> to HTTP/2. >> > > Do we agree that this header is not useful for HTTPS-schemed requests? > We do not. If a site relies on this feature to avoid mixed content, it may wish to downgrade unsupporting UAs to HTTP. They can't do that unless they know a priori whether or not the UA supports the feature. -mike
Received on Tuesday, 30 June 2015 19:28:59 UTC