Re: UPGRADE: 'HTTPS' header causing compatibility issues.

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"?


On Tue, Jun 30, 2015 at 7:51 AM, Mike West <> wrote:

> On Tue, Jun 30, 2015 at 11:40 AM, Anne van Kesteren <>
> wrote:
>> On Tue, Jun 30, 2015 at 11:18 AM, Adrian Hope-Bailie
>> <> 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 <>, @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