This seems worth a little bikeshed paint. 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. 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. Perhaps we could borrow a page from SIP here [1], and use something like "Supported: upgrade-insecure-requests"? [1] http://tools.ietf.org/html/rfc3261#section-8.1.1.9 On Tue, Jun 30, 2015 at 7:51 AM, Mike West <mkwst@google.com> wrote: > On Tue, Jun 30, 2015 at 11:40 AM, Anne van Kesteren <annevk@annevk.nl> > wrote: > >> On Tue, Jun 30, 2015 at 11:18 AM, Adrian Hope-Bailie >> <adrian@hopebailie.com> wrote: >> > I would suggest that it's simply the header name causing the issue and >> > changing to "TLS" or "HTTPS-Preferred" or similar will solve it. >> >> Slight preference towards avoiding TLS in names as long as OE is a thing. >> > > Slight preference towards avoiding a month-long bikeshed-painting > expedition. :) > > Since Chrome isn't likely to implement OE, "TLS" is ambiguous only in > Firefox at the moment. It's not clear to me that it's worth worrying > about... Also, "TLS" is short. > > If you have a concrete suggestion, though, I'd happily consider it! > > -mike > > -- > Mike West <mkwst@google.com>, @mikewest > > Google Germany GmbH, Dienerstrasse 12, 80331 München, > Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der > Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth > Flores > (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) >
Received on Tuesday, 30 June 2015 12:26:44 UTC