New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pick the shortest reasonable Prefer / upgrade header #216

Closed
pde opened this Issue Mar 17, 2015 · 13 comments

Comments

Projects
None yet
5 participants
@pde
Contributor

pde commented Mar 17, 2015

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.

@pde pde changed the title from Pick the shortest possible Prefer / upgrade header to Pick the shortest reasonable Prefer / upgrade header Mar 17, 2015

@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Mar 17, 2015

Member

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

Member

mikewest commented Mar 17, 2015

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 mikewest added the UPGRADE label Mar 17, 2015

@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest
Member

mikewest commented Mar 17, 2015

@igrigorik

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Mar 17, 2015

Member

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?

Member

igrigorik commented Mar 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Mar 17, 2015

Member

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

Member

mikewest commented Mar 17, 2015

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

@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Mar 17, 2015

Member

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

Is there a name that works? At all?

Member

mikewest commented Mar 17, 2015

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

Is there a name that works? At all?

@igrigorik

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Mar 17, 2015

Member

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

Member

igrigorik commented Mar 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Mar 17, 2015

Member

:(

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.

Member

mikewest commented Mar 17, 2015

:(

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

This comment has been minimized.

Show comment
Hide comment
@pde

pde Mar 18, 2015

Contributor

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

Contributor

pde commented Mar 18, 2015

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

@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Mar 18, 2015

Member

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.

Member

mikewest commented Mar 18, 2015

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.

@mikewest mikewest closed this in d7d9fc0 Mar 18, 2015

@pde

This comment has been minimized.

Show comment
Hide comment
@pde

pde Mar 18, 2015

Contributor

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

Contributor

pde commented Mar 18, 2015

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

@pde

This comment has been minimized.

Show comment
Hide comment
@pde

pde Mar 18, 2015

Contributor

I suspect HTTPS: 1 is more googleable though.

Contributor

pde commented Mar 18, 2015

I suspect HTTPS: 1 is more googleable though.

@Krinkle

This comment has been minimized.

Show comment
Hide comment
@Krinkle

Krinkle Jul 1, 2015

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

Krinkle commented Jul 1, 2015

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

@glensc

This comment has been minimized.

Show comment
Hide comment
@glensc

glensc Jul 19, 2017

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.

glensc commented Jul 19, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment