Not long ago I ran across a problem playing MP3s from a web site, and the problem’s presentation left me scratching my head.

A client was playing MP3s located on his site through an embedded media player in numerous pages throughout the site. No problem.

But in certain instances the same client was linking directly to the MP3s on a few pages, not using an embedded media player. When clicking the link to the directly-linked-to-MP3, it would play for a few seconds, then stop. And this was happening only in Firefox and Google Chrome (which wouldn’t play the embedded version either). All other browsers seemed to handle the direct link to the MP3s adequately.

There was nothing wrong with the MP3s. I downloaded them and played them directly via iTunes, with no stuttering or stopping prematurely.

Also consider that the site’s static content – MP3s included – was being served by Apache/squid to lighten the load on the Django installation upon which the site was built.

Using Firebug in Firefox to look at the response headers from the server when calling the MP3s directly, I noted that the Content-Length header was not being set. So the receiving browser was not informed how much data was coming its way. Was that the problem? If so, why was it an issue only in Firefox and Chrome?

Finally Peter Green from the good folks at The Agathon Group (where the site is hosted) noticed that mod_deflate – used to gzip the MP3 before sending it to the browser – was not allowing the Content-Length header to be set. Peter added this to the server's httpd.conf:

SetEnvIfNoCase Request_URI .mp3$ no-gzip dont-vary

…which turns off gzip compression for MP3 files. And magically the MP3s played properly when linked to directly.

Lesson: Firefox and Chrome can be very finicky if Content-Length headers are not set when serving up media files like MP3s.