NEW 63552
mp3 file misidentified as live stream
https://bugs.webkit.org/show_bug.cgi?id=63552
Summary mp3 file misidentified as live stream
Eric Carlson
Reported 2011-06-28 12:09:46 PDT
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.
Attachments
test mp3 file (8.16 KB, audio/mp3)
2011-06-28 12:09 PDT, Eric Carlson
no flags
Eric Carlson
Comment 1 2011-06-28 12:14:35 PDT
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.
Jer Noble
Comment 2 2011-06-28 12:26:30 PDT
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.
Jer Noble
Comment 3 2011-06-28 12:30:42 PDT
> 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
Alexey Proskuryakov
Comment 4 2011-06-28 12:46:32 PDT
FWIW, bug 56751 was about opening a local file, so no HTTP headers there.
Jer Noble
Comment 5 2011-06-28 18:41:18 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.