I'm attempting to embed an HTML5 audio element pointing to MP3 or OGG data served by a PHP file . When I view the page in Webkit (nightly or Safari 4), the controls appear, but the UI says "Live Broadcast." When I click play, the audio starts as expected. Once it ends, however, I can't start it playing again by clicking play. Even using the JS API on the audio element and setting currentTime to 0 fails with an index error exception. I suspected the headers from the PHP script were the problem, particularly missing a content length. But that's not the case. The response headers include a proper Content-Length to indicate the audio has finite size. Furthermore, everything works as expected in Firefox 3.5+. I can click play on the audio element multiple times to hear the sound replay. If I remove the PHP script from the equation and serve up a static copy of the MP3 file, everything works fine in WebKit / Safari. Does this mean Safari is treating audio src URLs with query parameters differently than URLs that don't have them? If so, it seems like a bug for webkit to assume that anything coming from a URL with query parameters is a live stream. My simple test page is: <!DOCTYPE html> <html> <head></head> <body> <audio controls autobuffer> <source src="say.php?text=this%20is%20a%20test&format=.ogg" type="audio/ogg" /> <source src="say.php?text=this%20is%20a%20test&format=.mp3" type="audio/mpeg" /> </audio> </body> </html> HTTP Headers from the PHP script: HTTP/1.x 200 OK Date: Sun, 03 Jan 2010 15:39:34 GMT Server: Apache X-Powered-By: PHP/5.2.10 Content-Length: 8993 Keep-Alive: timeout=2, max=98 Connection: Keep-Alive Content-Type: audio/mpeg HTTP Headers when directly accessing the MP3 file: HTTP/1.x 200 OK Date: Sun, 03 Jan 2010 20:06:59 GMT Server: Apache Last-Modified: Sun, 03 Jan 2010 03:20:02 GMT Etag: "a404b-c3f-47c3a14937c80" Accept-Ranges: bytes Content-Length: 8993 Keep-Alive: timeout=2, max=100 Connection: Keep-Alive Content-Type: audio/mpeg I tried hard-coding the Accept-Ranges header into the script header too, but no luck.
Does your server actually support byte range request like it advertises?
The problem did boil down to ranges not being supported properly. However, the sequence of requests tried by Safari at least seemed less than ideal perhaps. http://stackoverflow.com/questions/1995589/html5-audio-safari-live-broadcast-vs-not
Closing as "won't fix" as there is nothing to do in WebKit. Following up with the QuickTime team about the unusual pattern of requests.