Comment by da39a3ee

> I don't see it. When is/was HTTP ever really extended?

Most recently, HTTP/2 has become a concern that HTTP servers and clients have required substantial work to implement, but it is easy to say this is a separate protocol from HTTP, because even though it shares the same ports, a client that doesn't speak HTTP/2 when speaking to an HTTP server will not have to deal with them.

HTTP/1.1 wasn't like that, and neither was HTTP/1.0.

The original HTTP "0.9" was really a lot like finger: You would open a port, send a single line identifying the resource you wanted, and then the content would come back, and the connection would close. HTTP/1.0 added headers and some (text-based) framing to this, and fortunately there weren't many clients to upgrade.

Sometime in HTTP/1.0 people started talking about "pipelining" and the need to change the protocol to support this. The "Connection" header was introduced to identify this change - no other header had ever before meant anything to the web server (except when acting in some capacity as an application header), and misunderstanding the Connection header led to hung clients and slow response. This was made more annoying when the defaults changed for HTTP/1.1 -- now the "new" protocol was the default, and thus hung even more clients. I personally find this very funny because there is absolutely no need for a "pipelining" protocol- sockets are actually quite cheap, but most of the http server implementations and most of the http client implementations were badly written, and it may have been difficult to do better (assuming they knew how to do better) -- and so regardless, what was once an HTTP-compliant implementation was suddenly not.

HTTP/1.1 also introduced an "Upgrade" header, which was a kind of "trap door" to add extensions-- hopefully to avoid this kind of problem in the future, but it is complex, and many HTTP implementations simply added support for the "Connection" header and were find for a couple decades where today we are still shaking out clients that don't support Upgrade properly (and never noticed because servers vary on when they use it).

These "extensions" are the sort that everyone had to cope with- and because the protocol was carelessly defined, it was easy for implementations to get it wrong in a subtle way. Most of the other extensions (e.g. DAV, CONNECT, etc) are much easier to ignore simply because they're more "obviously" an extension.

> I think HTTP only really won because of those (HTML/CSS/JS).

HTTP won for a lot of reasons, and being easy to implement "mostly (or sufficiently) right" is a huge factor that I don't think should be ignored: Yes, many clients got it wrong and noticed years later, but "fixing" those broken clients was pretty easy, and the fact that people don't have to start over to gain increased compatibility or features is attractive in a way that should be studied by protocol designers trying to invent the next amazing thing.

> When is/was HTTP ever really extended?

https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

Only a few of those existed in the 1.0 spec. The rest evolved in practice. You can add your own without asking anyone else. Libraries don't have to be changed. Your payloads are your business. Encodings are flexible and negotiable.

> i think HTTP only really won because of those.

It's proven to be a predictable, stable, extensible, compatible, generic information exchange protocol. If it's won, it's because of that.

I'd go out on a limb here and wager that the majority of HTTP servers and clients aren't transferring HTML/CSS/JS. Moreover, the majority are probably not even talking to a web browser.

> When is/was HTTP ever really extended?

For example, WebDAV is a set of extensions to HTTP.

And in my opinion cross origin resource sharing headers could be considered an extension too maybe.