[upgrade] return=secure-representation

A) This is a horrible, horrible name.

1) What does it mean for a returned representation to be 'secure' -- is it that the links in it are to secure resources, or that it itself is secure?

2) There's no good reason to overload the existing 'return' preference, because the client is requesting a *redirect* to a different resource, not a representation of the current resource (<http://httpwg.github.io/specs/rfc7231.html#identification>).

3) It's long -- who will save the little network bytes? Yes, h2 has header compression, but that's no reason to be so needlessly verbose.

I'd suggest either:

Prefer: redir2sec

... or creating another, even shorter request header altogether (they're cheap).


B) If the server is making decisions based upon the presence or absence of this directive, it needs to either be a) uncacheable or b) listed in Vary.

Example 3 should be updated to something like:

---8<---
A client that supports this document's upgrade mechanism requests http://example.com/ as follows:

  GET / HTTP/1.1
  Host: example.com
  Prefer: redir2sec

The server parses the reference, notices that the users' client can deal well with upgrade requests, and therefore responds to the request by redirecting the user to a secure version of the resource she's requesting:

  HTTP/1.1 302 Moved Temporarily
  Location: https://example.com/
  Vary: Prefer

Note that Prefer is listed in the Vary header, since otherwise the redirect response could be served by caches to clients that don't support this mechanism. The same effect can be achieved by making it uncacheable;

  HTTP/1.1 302 Moved Temporarily
  Location: https://example.com/
  Cache-Control: no-store

See [RFC7235] for more information.

--->8---


(Note that Connection: keep-alive is *not* relevant in HTTP/1.1).


--
Mark Nottingham    mnot@akamai.com    https://www.mnot.net/

Received on Friday, 13 March 2015 04:49:35 UTC