51

My beginning 'facts' in this question are:

  1. HTTP is essentially nothing more than a file transfer protocol that only moves HTML.
  2. Networked file transfer protocols were well established by 1991, were widely available on numerous platforms, including NeXTSTEP, and Tim would've known about them.
  3. Browsers, while bundling an HTTP client for convenience, don't actually care how the HTML gets there, and will happily render HTML retrieved via FTP or any other method, particularly before the advent of CSS/JS/etc. Some browsers even have FTP support built in.

So with these above assumptions in place, why even bother with HTTP? It just seems like reinventing the wheel, when FTP was ripe to be made the underlying transport for HTML data. Obviously FTP clients wouldn't have the ideal UX for Tim's vision of the WWW, but it wouldn't have been difficult to customize a FTP client to work smoothly with HTML.

I think we know now in hindsight that FTP probably wouldn't have been a good choice especially at the global scale that the web has come to be, but I question whether Tim could've foreseen that. At the scale the internet was in 1991 - FTP probably made sense.

I'm sure one of my assumptions in this is faulty, which explains the existence of HTTP. Can someone shed some light here?

Improve this question
15
  • 43
    The FTP protocol is quite complex, involving multiple connections and persistent state, with a bunch of overhead as a result. HTTP is much simpler, using a single, stateless connection
    – Chris Dodd
    Commented Apr 15 at 1:07
  • 16
    It is not true nowadays that HTTP only carries HTML content - consider the Content-Type header.
    – dave
    Commented Apr 15 at 1:13
  • 40
    Per the wikipedia page on FTP - "HTTP essentially fixes the bugs in FTP that made it inconvenient to use for many small ephemeral transfers as are typical in web pages."
    – dave
    Commented Apr 15 at 1:16
  • 8
    Your premise that HTTP is only for HTML is invalid. HTTP can carry just about any content type.
    – jwh20
    Commented Apr 15 at 21:12
  • 7
    Did you ever try to use FTP without a nice client? :D The simple bare-bones HTTP client that Tim developed for the web was literally "GET ip/url\r\n". That's it. Compare that to requesting a single file from an FTP server.
    – Luaan
    Commented Apr 16 at 8:01

1 Answer 1

Reset to default
81

The browser did, in fact, support retrieving pages over anonymous FTP from the beginning, and it also supported other protocols. But, some of the early documents mention additional features for hypertext that would merit a new protocol.

This document (by Tim Berners-Lee, from 1992 or earlier) lists some of the design goals for HTTP:

Why a new protocol?

[...]

The protocol we need for information access ( HTTP ) must provide

  • A subset of the file transfer functionality
  • The ability to request an index search
  • Automatic format negotiation.
  • The ability to refer the client to another server

FTP only provides the first of these. HTTP provided file transfer and search very early on, with the other ones implemented later.

This document (also by Tim Berners-Lee in 1992) also lists goals for the protocol, among them:

Purpose

When many sources of networked information are available to a reader, and when a discipline of reference between different sources exists, it is possible to rapidly follow references between units of information which are provided at different remote locations. As response times should ideally be of the order of 100ms in, for example, a hypertext jump, this requires a fast, stateless, information retrieval protocol.

FTP is a stateful protocol, and the whole design of the protocol is meant for browsing file hierarchies, not for jumping between pages on different servers as the web was meant to do.

There are probably other reasons that were considered, as well, but these seem to be the main ones for making a new protocol.

Improve this answer
7
  • 9
    Don't know when these were introduced, but HTTP also brings multiple verbs/methods (GET/PUT/POST/DELETE etc.) and a lot of very flexible meta-data in the form of headers, both in the request and the response.
    – jcaron
    Commented Apr 15 at 12:51
  • 9
    @jcaron added in the 1992 spec that became HTTP/1.0. The 1991 spec that was later documented as HTTP/0.9 had only GET and no headers.
    – hobbs
    Commented Apr 15 at 13:08
  • 3
    @jcaron: That's probably more Roy Fielding's work than Tim Berners-Lee's. While Fielding's dissertation Architectural Styles and the Design of Network-based Software Architectures was published in 2000, there was a lot of back-and-forth inspiration. Basically, the thesis is a generalization and abstraction of what makes the WWW successful, but at the same time, Fielding had been designing HTTP to be that protocol which drives the success of the WWW. Fielding was involved with the WWW long before 2000 – he co-founded Apache and …
    – Jörg W Mittag
    Commented Apr 15 at 16:02
  • 5
    Fielding views the WWW as more than just a distributed information system, but as a substrate and/or template for a distributed computing system, and the HTTP verbs map 1:1 to his ideas of Representational State Transfer (ReST).
    – Jörg W Mittag
    Commented Apr 15 at 16:10
  • 5
    @jcaron The innovation there isn't how many commands there are but how few. FTP had/has dozens.
    – Wlerin
    Commented Apr 16 at 0:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .