26

HTML tends to compress well, typically consisting of text interspersed with repetitive tags. Transparently compressing it for download is a fairly obvious optimization to save bandwidth.

When did Web servers start routinely doing this? Mozilla's development pages mentions that HTTP/2 in 2015 started compressing headers, but doesn't seem to say anything about compression of text in document bodies.

5
  • 8
    I’m voting to close this question because it's about a contemporary subject better-suited to SO, SU, or similar. Mar 27, 2023 at 9:56
  • agreed - gopher: that's definitely retro. ftp, though older, is still (barely) in use so for some questions yes but for most no. http/1.0: not at all.
    – davidbak
    Mar 27, 2023 at 13:12
  • 7
    Yes, I agree, HTTP isn't exactly retro. Not even 0.9 as many servers still support it. Then again, I would like to read this more of a historic question which can be on topic - even though it's not well formed :))
    – Raffzahn
    Mar 27, 2023 at 13:26
  • 1
    With a lot of HTTP libraries it is still pretty hard (i.e. not just setting an intuitive config option) to compress both request and response body.
    – AndreKR
    Mar 28, 2023 at 19:55
  • @AndreKR Libraries aren't exactly an argument when it's about (standard) usage is. At best they document individual choices and application expectation.
    – Raffzahn
    Apr 2, 2023 at 13:57

3 Answers 3

47

Compression of document bodies is negotiated between clients and servers (and proxies), using notably the Accept-Encoding header: the client indicates which compression algorithms it supports, and the server chooses one as appropriate for the content being served (e.g. a JPEG file shouldn’t be compressed again) and the context of the negotiation (e.g. TLS sessions can be compressed, so there’s no point in serving compressed content in that context).

HTTP/1.0 (1996) already supported compress and gzip; more were added in HTTP/1.1. Compression was supported before HTTP/1.0 was published, at least by CERN httpd (in 1994). The use of compression was common early on: GIF and JPEG for images of course, and dynamically-negotiated compression for text. I don’t have historical references for the latter but I do remember it being a common part of setting up a web server in the nineties (although mis-configured servers weren’t rare).

4
  • 4
    Around 2005-2010 there was a well known bug or exploit (forgot the details) involving IE when accepting compression. Servers were routinely configured to automatically compress text except when IE is detected.
    – slebetman
    Mar 28, 2023 at 8:30
  • 3
    Note that in 1994, according to W3C there were only 623 web servers.
    – T.E.D.
    Mar 28, 2023 at 13:33
  • 3
    @T.E.D. Those early-mid 90s figures look a bit dubious from memory
    – Mick O'Hea
    Mar 28, 2023 at 20:13
  • 4
    @MickO'Hea - You might know better than me, but I think that's about the year I first started using the Web, and for a while indexes rather than search engines were a perfectly reasonable way to look around. It was a year or two before I had to give up on indexes and start just searching for sites. In fact, it was a while before it became more useful for me than gopher.
    – T.E.D.
    Mar 28, 2023 at 22:18
11

http/0.9 didn't have any headers, and so couldn't support compression.

On the other hand, http/1.0 (rfc1945, May 1996) already had that support. It was already on draft-00 (as Content-Encoding: x-gzip), dated November 28, 1994.

Do note that HTTP/1.0 was first implemented, then published as an informational RFC. See one of the first messages on the working group.

This 1992 version of HTTP already included Content-Encoding (despite the title, I suspect the page contents might reflect a later year than 1992, though)

First version of gzip program (gzip 0.1) was first publicly released on 31 October 1992, and version 1.0 followed in February 1993. (Wikipedia)

Thus, compression support must have been added to http around 1992-1993.

Of note, NCSA Mosaic (started around those dates) doesn't support Content-Encoding header.

Since Content-Encoding is a negotiated header in HTTP, it is transparent, as soon as clients started using HTTP/1.0 the servers would have started compressing responses when they could (i.e. almost on every static file they served).

4

I surfed the entire web once -- I fired up NCSA Mosaic, found there were only about a dozen web sites up at the time, and pulled up at least the front page on all of them. I don't recall Netscape 0.9 (came out in 1994) supporting HTTP compression. But my recollection is by 1995 or so, HTTP compression was already fairly widespread.

You must log in to answer this question.

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