HTTP 304 and GZIP: Our Best Friends

The HTTP 304 response is likely one of the most underrated pieces of big ol' RFC 2616.

Mad props to Om Malik for surfacing the above article in his very-well researched piece on Safari, Tiger, RSS and the Bandwidth Bottleneck.

I also think we need to bring Accept-Encoding: gzip / Content-Encoding: gzip back to the foreground. Back when Netscape 4.x was too pervasive, there were a few issues that made many of us shy away from leveraging gzip:

• Unreliable client-support: I remember issues where Netscape would crash upon receiving a .css or .js file over gzip
• gzip adds CPU load on busy servers handling many requests per second. In those days of slower CPUs, it was often best to offload this work on dedicated hardware/proxies, or not do it. Today CPUs are fast.

I've heard scattered rumors of certain user agents who do send the accept-encoding gzip request header, yet barf on the gzipped data. I've yet to see one such user agent, please share the info if you have it :) Some shops will enable gzip Content-Encoding based upon a list of allowed user agents. That works too, albeit not ideal .

Google.com serves its pages over gzip, provided you send it a user-agent of a decent web browser.