On Tue, Jul 7, 2015 at 8:10 AM, Mike West <mkwst@google.com> wrote: > On Wed, Jul 1, 2015 at 11:03 PM, Yoav Weiss <yoav@yoav.ws> wrote: > >> A static set of "Prefer" headers would mean that (very much like >> "Accept") in case that content varies on `Prefer`, intermediate caches >> would have to maintain ~ a copy per UA. The damage can be minimized if UAs >> coordinate to make sure that similar `Prefer` values are *identical* >> between the different UAs. >> >> That's not *awful*, but in terms of caching, a separate header name is >> better, at least until `key >> <https://tools.ietf.org/html/draft-fielding-http-key-02>` becomes a >> thing. >> >> Is "Upgrade-Insecure-Requests: yes pleasssssse" much worse than "Prefer: >> upgrade-insecure-requests"? >> > > It sounds like there's general agreement that `Prefer` is the right > semantic to use here, but there's concern (and disagreement) about whether > or not the caching impact a) exists, b) overrides the semantic value. > > If there's a clear solution for the caching problem (`key`), and we're > just waiting for it to be deployed, then I'd prefer `Prefer`. :) > > Is that a crazy stance? Are there sincere impacts to the Internets that > I'm missing? If not, I'll update the spec to `Prefer: secure-transport`. > I still feel like "secure-transport" doesn't accurately capture the semantic you're after here. I thought we were trying to say "It's safe to upgrade me because I support upgrade-insecure-requests", with the emphasis on the latter thing. So maybe "secure-upgrade"? (This is also why I would prefer "Supported: upgrade-insecure" over "Prefer", but I'm not hard over on that.) (I know this sounds like bikeshedding, but it's important to get the conceptual model right here. Both to be clear in the spec, and to have a clear path forward.) --Richard
Received on Tuesday, 7 July 2015 17:35:13 UTC