Browser-based file transfer

The channel is HTTPS. RFC 9110 supplies GET for the download and POST or PUT for the upload. The constraint is the browser: tabs sleep, mobile browsers kill background requests, and a single long POST has no standard resume.

That constraint decides the product. A 10 MB PDF can be one form post. A 8 GB master cannot. A serious browser upload uses resumable chunks, shows a byte count, and survives the laptop lid. A download uses the browser's download manager, which may support Range, or it streams into a blob the tab must keep alive. Tell the user which of those they are getting. "It works in the browser" does not say which.

A client opens a delivery page and clicks a 4 GB link. The browser starts a GET, the user switches apps, and the mobile browser suspends the tab at 1.1 GB. A server that supports Range lets them continue. A server that does not forces a restart, and the partial file in the download list looks done. The upload direction is harsher. A photographer posts 6 GB from a phone browser on hotel Wi-Fi. Without tus-style offsets, the 30-minute mark kills the request and the server stores nothing. With offsets, the page reloads, reads the offset, and finishes. WebDAV mounts and SFTP clients are the alternative when the browser keeps failing. They are installed clients, so they are outside this term.

Browser transfer still needs access control and expiry. The padlock is TLS. It is not a permission. A public page with a file input is an open dropbox.