Created attachment 98955 [details] test mp3 file OS X media engine misidentifies attached mp3 file as a live stream when loaded from the network. It is opened correctly when opened locally.
Originally reported as https://bugs.webkit.org/show_bug.cgi?id=56751. That was closed as "works for me" even though the bug remains, so this was filed.
The bug might have something to do with either the MIME type being sent by the webkit.org server, or the lack of an extension on the URL itself. When downloading the file to my local machine, renaming it a .mp3 file, serving it via HTTP from localhost, and playing in Safari, it behaves normally.
> curl -I -o - 'https://bug-63552-attachments.webkit.org/attachment.cgi?id=98955' HTTP/1.1 200 OK Date: Tue, 28 Jun 2011 19:28:56 GMT Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/1.0.0c DAV/2 mod_python/3.3.1 Python/2.6.6 PHP/5.2.17 Content-disposition: inline; filename="atari.mp3" Content-length: 8358 Access-Control-Allow-Origin: http://build.webkit.org/TestFailures/ Strict-Transport-Security: max-age=7776000 Connection: close Content-Type: audio/mp3; name="atari.mp3" vs.: > curl -I -o - 'http://localhost/~jer/atari.mp3' HTTP/1.1 200 OK Date: Tue, 28 Jun 2011 19:30:07 GMT Server: Apache/2.2.19 (Unix) DAV/2 Last-Modified: Tue, 28 Jun 2011 19:24:01 GMT ETag: "13c2ca1-20a6-4a6ca9c327640" Accept-Ranges: bytes Content-Length: 8358 Content-Type: audio/mpeg
FWIW, bug 56751 was about opening a local file, so no HTTP headers there.
(In reply to comment #4) > FWIW, bug 56751 was about opening a local file, so no HTTP headers there. Actually, that bug looks like it worked correctly when served as a local file, but not when served remotely.