One purpose of the Upgrade mechanism in RFC 2817 was the provide a virtual hosting mechanism for HTTP with TLS as the situation was back in 2000:
The Upgrade mechanism also solves the "virtual hosting" problem.
Rather than allocating multiple IP addresses to a single host, an
HTTP/1.1 server will use the Host: header to disambiguate the
intended web service. As HTTP/1.1 usage has grown more prevalent,
more ISPs are offering name-based virtual hosting, thus delaying IP
address space exhaustion.
The Server Name Indication (SNI; RFC 3546, 3.1) gave a better solution to this problem in 2003 – the one still in use – so there has not been need for this anymore. The Upgrade
header is still alive but used for different purposes like switching from HTTP/1.1 to HTTP/2.0 (RFC 7230, 6.7).
The HTTP protocol also has the Location
header (RFC 7231, 7.1.2) with the related response codes, making it easy to redirect the client to another scheme, host and port, unlike the protocols that were using STARTTLS
.
Also notice that using STARTTLS
was not something good and desirable and something that should be adopted by more protocols. In fact, RFC 8314 now obsoletes the cleartext protocols for email submission and access, leaving MTA-to-MTA SMTP the only email protocol where STARTTLS
should be used. From section 3:
– – Although this mechanism has been deployed, an alternate mechanism
where TLS is negotiated immediately at connection start on a
separate port (referred to in this document as "Implicit TLS") has
been deployed more successfully. To encourage more widespread use of
TLS and to also encourage greater consistency regarding how TLS is
used, this specification now recommends the use of Implicit TLS for
POP, IMAP, SMTP Submission, and all other protocols used between an
MUA and an MSP.