Prefer has the advantage of being an existing header, which means that in the best case (when Prefer was already being sent by the client), we'd be at 4 characters ,tls. I think it's reasonable to stop where we are. :)

+@igrigorik

Is there any case under which "Prefer: https" might affect the caching policy? If so, then we should split it into a separate header due to limitations of Vary. If not, then +1 for "Prefer: https"... because clarity is good, and TLS is not the only secure transport option - e.g. QUIC?

@mnot suggested that Vary: Prefer would do what we need (see the example in the doc). Is that not the case?

Also, I forgot about QUIC, et al, and discounted opportunistic encryption. Ugh.

Is there a name that works? At all?

If "https" is the only token advertised via Prefer, yes that's fine. However, the fact that its an existing header means that other values may be advertised as well, at which point "Prefer: x,y,z" forces "x,y,z" to become part of the cache key, evne if x and y have no business of being part of the cache key.

I went through same exercise with CH, see: igrigorik/http-client-hints#14

:(

HTTPS: plz? We can't use Upgrade, as that already has meaning. U is a thing, I guess, but I really don't like that it's completely incomprehensible on the one hand and ungoogleable on the other.

Sec: Y, Sec: 1, HTTPS: Y, HTTPS: 1?

HTTP: S. sigh All of these are, to quote @mnot, horrible horrible. :(

If it's going to be horrible horrible, HTTPS: 1 seems at least descriptively horrible. Let's run with that for the moment.

HTTP: S may be many kinds of horrible, but it's also poetry :)

I suspect HTTPS: 1 is more googleable though.

@pde It is, and thanks!

Searching "HTTPS: 1 header" led me to
http://www.w3.org/TR/upgrade-insecure-requests/
 ^{(which in turn points here)}

HTTPS: 1 was horrible decision, as such header is quite commonly used in proxy solutions, so backend servers received: CGI variable like HTTP_HTTPS: 1, on and that broke quite some setups.

Luckily that HTTPS: 1 existed only shorty, Chrome/44 only, and was changed to upgrade-insecure-requests header later.