It sounds like we're moving away from it, but another quick bikeshed vote away from "TLS" from a futureproofing perspective -- I think we probably all regret how many names of things got "SSL" baked into them... -- Eric 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). > > 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.` > > -mike > -- konklone.com | @konklone <https://twitter.com/konklone>
Received on Tuesday, 30 June 2015 14:19:28 UTC