Un scop al Mecanism de upgrade în RFC 2817 a fost furnizarea a gazduire virtuala mecanism pentru HTTP cu TLS, deoarece situația era în 2000:
Mecanismul de Upgrade rezolvă și problema „găzduirii virtuale”.
În loc să aloce mai multe adrese IP unei singure gazde, an
Serverul HTTP/1.1 va folosi antetul Host: pentru a dezambigua
serviciul web destinat. Pe măsură ce utilizarea HTTP/1.1 a devenit mai răspândită,
mai mulți ISP-uri oferă găzduire virtuală bazată pe nume, întârziind astfel IP-ul
epuizarea spațiului de adrese.
The Indicarea numelui serverului (SNI; RFC 3546, 3.1) a dat o soluție mai bună la această problemă în 2003 – cea încă în uz – așa că nu a mai fost nevoie de aceasta. The Modernizare antetul este încă viu, dar este folosit în diferite scopuri, cum ar fi trecerea de la HTTP/1.1 la HTTP/2.0 (RFC 7230, 6.7).
Protocolul HTTP are și Locație antet (RFC 7231, 7.1.2) cu codurile de răspuns aferente, facilitând redirecționarea clientului către o altă schemă, gazdă și port, spre deosebire de protocoalele care foloseau STARTTLS.
Observați, de asemenea, că folosind STARTTLS nu a fost ceva bun și dezirabil și ceva care ar trebui adoptat prin mai multe protocoale. De fapt, RFC 8314 acum depășește protocoalele de text clar pentru trimiterea și accesul la e-mailuri, lăsând MTA-la-MTA SMTP singurul protocol de e-mail în care STARTTLS ar trebui folosit. Din secțiunea 3:
â â Deși acest mecanism a fost implementat, un mecanism alternativ
unde TLS este negociat imediat la începerea conexiunii pe a
port separat (denumit în acest document „TLS implicit”) are
a fost implementat cu mai mult succes. Pentru a încuraja o utilizare mai răspândită a
TLS și, de asemenea, să încurajeze o mai mare coerență în ceea ce privește modul în care este TLS
utilizată, această specificație recomandă acum utilizarea TLS implicită pentru
Trimitere POP, IMAP, SMTP și toate celelalte protocoale utilizate între un
MUA și un MSP.
