I wasn't really planning on asking this quesiton here, but since somebody needs to make use of this forum, I thought I'd be the first to post an on-topic off-topic post.

I'm having an issue with the mp3 server app I'm writing for myself (not run on the empeg, but rather on my Win2K/IIS server and using the empeg csv export and fid backups). I got everything mostly working, but when I use the header Content-Length when sending a mp3 file, PHP (which is what the app is writen in) throws me a fatal error about the script timeout after 30 seconds.

I find that a bit wacky, since it always sends the entire mp3 regardless of song length, and then appends the text of the error message to the end of the data. I only noticed this when trying to figure out why the ID3 tags were lost during download. Turns out that they weren't really lost, but the error message text at the end of the file hosed it up. The file still played fine, though..which is why I didn't notice it at first.

Sooo...I thought maybe I was just sending a bad value for content-length, but I can't imagine that causing this type of behavior. I tried using both the length field from the csv export, and PHP's filesize funtion on the fid when reading the data to send. The script throws the fatal error in either case.

I disabled that particular header and everything works fine, ID3 tags and all. I was thinking it would be better if the browser knew how much data to expect, no? At least IE was telling me x of x mb with the header there, which I don't get now, but I get a non-hosed mp3 file.

Any suggestions? Does the content-length header matter that much to my web browser, or Winamp (when streaming instead of straight download)? Should I care?

Sorry for being on-topic...

Generally, neither IE nor WinAmp care that the Content-Length header is there. Don't worry about it. If you're really interested, pull up a cup of coffee and delve into the delights of RFC2616. To summarise:

In HTTP/1.0, the Content-Length is a courtesy -- it tells the browser how much data to expect. The end of the data is actually signalled by the connection closing. If the amounts don't match, a sensible browser will warn you.

Thus, the Content-Length header is optional.

In HTTP/1.1, it becomes more important. HTTP/1.1 added the ability to use a single TCP connection for multiple requests/responses. This reduces the load on the client and the server.

However, this means that the browser needs to know when one response has finished and the other begins. Content-Length becomes more important for this. It's still valid to close the connection to signify end-of-file.

This complicates the issue if the server doesn't know how big the file is. For this, Transfer-Encoding: chunked is used.

Alrighty...thanks. I won't worry about it anymore.