No, wait. I'm being totally serious. When HTTP was invented, FTP already existed. Why couldn't FTP be the web's transport protocol?
Sure, it has a lot of missing feautres, but most were added as an afterthought to HTTP and could be added to FTP too, such as caching, compression, virtual hosting.
You could event think of a protocol like CGI that allowed to automatically generate FTP files (pages).
HTTP stands for Hypertext Transfer Protocol. At it's most basic, it allows for the communication between different systems. It's most commonly used to transfer data from a web server to a browser in order to allow users to view web pages. It's the protocol that was used for basically all early websites.
The only difference between the two protocols is that HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses, and to digitally sign those requests and responses. As a result, HTTPS is far more secure than HTTP. A website that uses HTTP has http:// in its URL, while a website that uses HTTPS has https://.
Without HTTPS, any data passed is insecure. This is especially important for sites where sensitive data is passed across the connection, such as eCommerce sites that accept online card payments, or login areas that require users to enter their credentials.
You don't need to include the protocol (the browser uses HTTP by default) or the port (which is only required when the targeted Web server is using some unusual port), but all the other parts of the URL are necessary.
Yes, you can serve HTML files using FTP. However FTP is a heavy-weight, stateful, protocol and assumes you will be staying on the same server. It is optimized for downloading larger files (where the setup overhead is amortized over the size and number of downloads) HTTP is very light-weight (you can communicate to an HTTP server using TELNET much easier than FTP, especially before PASSIVE FTP) and is designed around HTML -- the concept that in the course of your navigation you will be visiting many different servers and grabbing only a couple of files at a time from each.
Gopher existed before HTML and was very popular. It was also a light-weight protocol. It just didn't have the presentation and ease of entry that HTML had.
The short answer is, people invented all sorts of protocols for all sorts of reasons (i.e. doctoral theses) -- HTTP managed to come along at the right time and have the right set of features.
BTW, CGI wasn't even a part of HTTP at the beginning. It came along later -- and it was far easier to shoehorn CGI into HTTP than into FTP because of the simple, stateless protocol.
Oh, and there was no "web" before HTTP/HTML. The web needs HTTP because HTTP created the web.
There's no reason you couldn't. It would have been cumbersome, tacky and annoying though. I mean, you can make a boat out of a VW bug body. Doesn't mean it's a good idea.
http is a protocol for downloading files with a displayable (by definition) format. FTP is optimized for exchange of files of all types and the download of directory information.
Could you have shoe-horned a display-oriented modification into FTP? Yes. Would it provide any benefit over a more custom-tailored protocol with a simpler interface? No.
By the time the Web was coming together, FTP was already becoming cumbersome even for the simple exchange of files (i.e. what is was designed to do). It's a quirky and sometimes ambiguous protocol that doesn't play well with firewalls. People were already coding workarounds into FTP clients to try to sniff out what server software the FTP site was using to workaround its bugs.
In short, not the kind of thing you would base a new technology on.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With