Summary

  • RFC 2817 proposed starting TLS inside an existing HTTP/1.1 connection, allowing plain and secured traffic to share port 80 and letting a clear HTTP Host field identify a virtual host before certificate selection.
  • The same RFC preserved the distinct https URI scheme and reported little interest, by 2000, in replacing port 443 for generic Web browsing. The companion RFC 2818 documented the TLS-first arrangement on that port.

The Web had built two front doors. Ordinary HTTP used port 80. An https address sent the visitor to port 443, where a TLS handshake began before the first HTTP request. At a December 1997 IETF meeting, application-area leadership reaffirmed that issuing a parallel secure port for every protocol was a habit worth retiring. Three years later, the standards track offered a tidy answer: put a lock on the door the visitor was already using.

RFC 2817, published in May 2000, proposed an HTTP/1.1 Upgrade to TLS/1.0 over the existing TCP connection. Plain and encrypted HTTP could share port 80. It also addressed a second late-1990s headache. Name-based virtual hosting let one IP address serve several hostnames because HTTP/1.1 carried a Host field. A TLS handshake before HTTP did not yet carry that name in the way the proposal needed for certificate choice. With an initial clear HTTP exchange, the server could read Host, choose the intended virtual host, and then begin TLS. The proposal asked the receptionist for a name before fitting the lock.

The mechanics were more careful than that metaphor. HTTP/1.1's RFC 2616 made Upgrade a change between neighboring HTTP peers. A client could include the TLS token and Connection: Upgrade in a request. If an unsecured answer was acceptable, the server could simply answer in the clear. When a clear answer was unacceptable, RFC 2817 directed the client to send OPTIONS * first. That harmless request was the room in which to negotiate the lock before sending a sensitive operation.

If the server accepted, it sent 101 Switching Protocols, named the ordered TLS/1.0, HTTP/1.1 stack and switched immediately after the response headers. The TLS handshake followed. Only after that handshake did the server continue the HTTP exchange under TLS. A server could also answer 426 Upgrade Required to say that a resource demanded a particular switch. The 426 was a demand, not the switch itself: the client still had to perform the Upgrade exchange. The status code placed a new instruction on the door rather than silently changing the hallway under a visitor's feet.

Proxies made the hallway longer. Upgrade operated one hop at a time; a proxy's 101 changed the client-to-proxy leg, and an origin's 101 changed the proxy-to-origin leg. For TLS reaching the origin, RFC 2817 described CONNECT to form a tunnel first, even to port 80. A successful 2xx response established that tunnel, after which the client could conduct the Upgrade exchange with the server. The one-port idea still needed a route through the intermediaries that had become part of the Web's daily furniture.

The largest complication lived in the address bar. The proposal explicitly kept http:// and https:// as different URI spaces. RFC 2818, published the same month, documented the already familiar arrangement: a client connects to port 443 by default, starts with a TLS ClientHello, then sends HTTP inside TLS; the https scheme signals that arrangement. RFC 2817's single-door mechanism could change how a connection was secured. It did not merge the names of the places visitors believed they were going.

RFC 2817 was frank about the moment it entered. It reported broad acceptance of the proposal's general idea but little interest in implementing an alternative to 443 for ordinary Web browsing. The text pointed to new protocols built over HTTP, including Internet Printing, as places where an Upgrade path might help the standards process. The engineering plan met an installed public habit inside the proposal's own introduction.

The shared-door design solved real problems on paper: fewer parallel well-known ports, certificate choice informed by the HTTP host name, and an explicit server demand for TLS. It also had to carry a clear preamble, an acceptance exchange, proxy tunneling and two distinct URI identities. The Web's old secure doorway was already painted into links and expectations. TLS could knock on port 80; https still had its own address.