On Tue, Jun 30, 2015 at 9:28 AM, Mike West <mkwst@google.com> wrote: > On Tue, Jun 30, 2015 at 2:26 PM, Richard Barnes <rbarnes@mozilla.com> > wrote: > >> This seems worth a little bikeshed paint. >> > > I'd like my lock to be neon green, please. > > >> I appreciate that "HTTPS" and "TLS" are short, but it seems like that >> comes at the cost of having any semantic content. Without staring at the >> spec for a few minutes, I have no idea what these mean. >> > > Totally agree. We ended up with "HTTPS" by allowing concerns regarding > number of bits on the wire to override those concerning clarity. > > Is it accurate to say that the goal here for the UA to indicate that it >> supports upgrade-insecure-requests? So that the server knows that it's >> safe to upgrade this client even if it relies on u-i-r to make HTTPS work >> without mixed content problems. >> > > Yes. > > >> Perhaps we could borrow a page from SIP here [1], and use something like >> "Supported: upgrade-insecure-requests"? >> > > An earlier version was an overly verbose `prefer` header, which Ilya shot > down due to caching concerns (e.g. `vary: prefer` would have bad results as > it's tied to the whole header value, as opposed to the specific preference). > If you happen to have a pointer handy, I would be interested to take a look at the history here. It does seem like Supported is different from Prefer. It's more like Accept -- it's OK if you send me content that depends on $FEATURE. > Still, this is a totally reasonable direction to move in. If we're fine > with the length, then why not `upgrade-insecure-requests: Totally > supported! Gimmie that HTTPS, please.` > Adding header bloat to HTTP/1.1 seems like a feature, not a bug :) For h2 users, there should be no need to use this thing, and for the poor souls doing h2c, HPACK. --Richard
Received on Tuesday, 30 June 2015 14:27:06 UTC