HTTPS

RFC 9110 defines the https URI scheme and the methods a client uses to fetch or send a representation. The file bytes ride in a GET, PUT, or POST body. TLS, in the current version RFC 8446, encrypts that exchange and checks the server name.

This is the path behind almost every browser transfer. A recipient clicking an expiring link issues a GET. A form upload issues a POST or PUT. There is no separate data port, which is why HTTPS survives networks that break FTP. The same TCP connection, or an HTTP/2 or HTTP/3 stream on it, carries the request and the file.

HTTPS encrypts the channel to the host named in the certificate. It does not decide who may use the URL. A public link on HTTPS is still public: anyone who has the URL can GET the object, and a watcher on the path cannot read it. Authorization is a header, a cookie, or a signature on the query string. Confusing the padlock with access control is the common miss.

A portal at `https://drop.example/u/8841` accepts a 900 MB POST. The certificate covers `drop.example`. The upload takes six minutes. Halfway, a corporate proxy with its own root re-terminates TLS, inspects the body, and opens a second TLS session to the origin. The browser showed a lock. The proxy held the file in the clear. Transit encryption held between browser and proxy, and again between proxy and origin. It was not end to end. If the job instead fails with a certificate name mismatch, the client never sent the file. That is a failed check on the host, not a slow link.

HTTP on port 80 is the same methods without TLS. Browsers mark it insecure, and intermediaries can alter the body. Range requests, content length, and status codes are HTTP behavior from RFC 9110. They work on both schemes. Only the privacy of the bytes and the check on the server name come from TLS.