Не удается повторно воспроизвести аудиофайл из репозитория Mercurial в Chrome

Question

В моем тестовом файле HTML5 я могу нормально воспроизводить и воспроизводить звуковой файл mp3, если:

1. Мои файлы хранятся локально, ИЛИ
2. Они размещаются на традиционном веб-хосте (см. http://sgdk2.enigmadream.com/ben/iotaBuildIt/sound.html) ИЛИ
3. Я играю в Internet Explorer

Я могу воспроизвести звук в первый раз, но не могу воспроизвести его во второй раз, если:

1. Файлы хранятся в репозитории Mercurial.
2. Я использую Chrome для доступа к файлу

(У меня нет проблемы при использовании IE для доступа к файлам, размещенным на Mercurial.)

В этих условиях я не могу повторно воспроизвести файл, когда:

1. Доступ к нему через HTML-страницу ( http://hg.code.sf.net/u/bluemonkmn/myiota/raw-file/97ac02a717fe/HTML/sound.html) a. Я не могу заставить его повторить сценарий и б. Я не могу использовать пользовательский интерфейс управления воспроизведением звука. NOR
2. Прямой доступ к файлу ( http://hg.code.sf.net/u/bluemonkmn/myiota/raw-file/97ac02a717fe/HTML/bing.mp3)

Может кто-нибудь объяснить или помочь мне исправить это, чтобы Chrome мог воспроизводить аудиофайлы, размещенные в Mercurial, как это делает IE? Также я не тестировал FireFox, и мне было бы интересно узнать, как он там работает.

Answer 1

Я сообщил об ошибке Chromium #129165 с подозрением, что это ошибка, поскольку она, очевидно, работает под управлением Linux.

Answer 2

Если бы мне пришлось угадывать, я бы сказал, что разница заключается в заголовках, которые предоставляет статический файл Apache и hgweb. Вот вывод для файла.mp3 из обслуживания статического файла Apache:

$ HEAD -Ssed http://sgdk2.enigmadream.com/ben/iotaBuildIt/bing.mp3
HEAD http://sgdk2.enigmadream.com/ben/iotaBuildIt/bing.mp3
200 OK
Connection: close
Date: Wed, 23 May 2012 16:55:03 GMT
Accept-Ranges: bytes
ETag: "4d0cbbe-16c7-4bd83a906c040"
Server: Apache
Content-Length: 5831
Content-Type: audio/mpeg
Last-Modified: Thu, 12 Apr 2012 23:24:41 GMT

и вот он исходит из обработчика необработанных файлов hgweb:

HEAD http://hg.code.sf.net/u/bluemonkmn/myiota/raw-file/97ac02a717fe/HTML/bing.mp3
200 Script output follows
Connection: close
Date: Wed, 23 May 2012 16:56:33 GMT
Server: Apache/2.2.3 (CentOS)
Content-Length: 5831
Content-Type: audio/mpeg
Content-Disposition: inline; filename="bing.mp3"

Большие различия в том, что Apache включает заголовок Accept-Ranges, а hgweb предоставляет заголовок Content-Disposition.

Content-Disposition Здесь заголовок только предлагает вашему браузеру имя файла по умолчанию для saveAs, так что это вряд ли виновник (но никто не знает).

Accept-Ranges заголовок интереснее. Хотя это и не оригинальная цель, он стал основой поиска потокового аудио и видео. Если снова подумать об игре как об особом случае поиска (стремиться к нулю), то, возможно, Chrome отключает это, потому что без Accept-Ranges заголовок, который он не думает, что может искать вообще (хотя, конечно, поиск к нулю - это просто игра с нуля снова).

Это определенно просто плевок, но это было бы достаточно легко проверить. Настройте ваш Apache хост hgweb, чтобы использовать mod_headers как это:

header add Accept-Ranges bytes

на пути, который управляет вашим hgweb (будь то WSGI или CSG). Пока вы на это, вы можете удалить Content-Disposition заголовок с mod_headers тоже.

В конце концов это все о байтах на проводе. Вы можете заставить hgweb и Apache возвращать одинаковые байты, и тогда Chrome будет обрабатывать их одинаково.

Примечание: это, конечно, тот случай, когда добавление Accept-Ranges: bytes заголовок к выводу hgweb фактически не добавляет поддержку диапазона байтов к hgweb, но это нормально. hgweb просто проигнорирует Range: bytes=xxxx заголовок и вместо того, чтобы дать 206 Partial Response статус это даст 200 OK и RFC говорит, что клиент (Chrome) должен иметь дело с этим. Таким образом, вы не сможете пропустить файлы, но для Chrome этого может быть достаточно, чтобы вы начали поиск / воспроизведение.