PUT request with HTTP authentication is quite standardized, isn't it?
The problem isn't that there are no standardized way of doing it. The problem is that the existing standardized way of doing it has no adoption, because it's not really optimal for current needs.
With FTP you login and are then in your home directory. Then you upload. With HTTP authentication is a home directory required? Can you do `pwd` to query your home folder. Some FTP clients allow standboxing where you are in /home/user folder but `pwd` says `/`.
There are like at least 3 different mainstream ways to "log in" to a web server, and all of them are more straightforward than FTP's insane mainframe-era control-channel/data-channel design.
The "sandboxing" you're referring to is a serverside chroot, for what it's worth. And, of course, web servers have been doing that since NCSA httpd.
Eh. When you realize that FTP supported opening two control channels to different systems and having them do a file transfer without involving the client, it makes more sense.
It was also possible for the client and server to fork off data handling processes for the data channel and continue to use the control connection without needing async poll/select loops.
It's the "without needing async poll/select loops" thing that makes it so crazy. It's a protocol that encodes the multiprocessing limitations of its hosts.
Frankly, I don't know why most people have chosen to use POST requests instead of PUT. Browsers and servers usually support both PUT and HTTP authentication, and when used over HTTPS it should be quite safe.
The problem isn't that there are no standardized way of doing it. The problem is that the existing standardized way of doing it has no adoption, because it's not really optimal for current needs.