Pick the shortest reasonable Prefer / upgrade header

[pde]

We've gone from Prefer: representation=secure to Prefer: https to Prefer: tls. That's pretty good, 11 characters, 13 bytes on the wire, but should we go further?

An even shorter option which I'm stealing from #212 is Upgrade: 1, 10 characters. Or we could do Pref: tls, 8 chacters. Or go all the way to TLS: 1 or HS: 1 for "hypertext secure", 5 characters, 7 bytes on the wire?

There are some aesthetic / clarity arguments for stopping at some point along this line, and I feel I lack data for where to put the pin.

[mikewest]

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. :)

[mikewest]

+@igrigorik

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

[mikewest]

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

[mikewest]

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

Is there a name that works? At all?

[igrigorik]

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

[mikewest]

:(

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.

[pde]

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

[mikewest]

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.

[pde]

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

[pde]

I suspect HTTPS: 1 is more googleable though.

[Krinkle]

@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)}