For the love of...
So, RFC 7838 explains (implicitly) how this is different from a simple HTTP redirect. It's transparent to the client. It's transparent to TLS - the alternative service has to provide a certificate that's valid for the original origin server. It's transparent to the request - the Host header doesn't change, for example.
What it doesn't say is why. Why is any of that desirable? The ostensible aims of Alternative Services, as explicitly detailed in the RFC, are all satisfied by HTTP redirects. (For that matter, some of them are satisfied by reverse proxies for many use cases, or by periodically terminating persistent connections and forcing clients to reconnect, the overhead of which amortized over many requests is negligible.)
I haven't tried to trawl through the discussion archives for the I-D to figure out what justification the authors1 came up with for this. Anyone know offhand?
1Incidentally, and while I don't mind the Google-bashing above (which is well-deserved in general; QUIC and the like are a pox), the authors of 7838 are from Akamai, Mozilla, and greenbytes. (The last, of course, is Julian Reschke, author of a number of HTTP features.) So usual suspects, in other words, but not directly the usual suspects of Google.
Biting the hand that feeds IT
