Perché lo streaming audio in Mobile Safari a volte non ha una barra di scorrimento?

Ecco la risposta fornita dal supporto di Rackspace Cloud Sites:

Our servers cannot stream media files so opening a media file such as an mp3 would be played back using a method called progressive download within a browser or device. The following article describes progressive downloading: http://en.wikipedia.org/wiki/Progressive_download

Basically, the media player will download the file from start to finish and allows you to play the portion of the file that has downloaded. iOS devices, like many other mobile devices, are limited in memory so will stop downloading the file after its internal buffer is full so that it can conserve what precious little RAM it has available. Though the download stops, the device will continue to play the portion of the media file it has downloaded so far. Once the device gets near the end of the downloaded data a new HTTP request is sent to resume downloading of the media file so that playback is uninterrupted. Once the download of new data resumes, the cycle starts again with the device pausing when its buffer is full.

In the case of this file, the resume step is failing as file download resuming is not supported on media files within our systems as can be seen by "Accept-Ranges: bytes" not being present within the headers of the HTTP response for this file:

HTTP/1.1 200 OK Server: Apache/2.2
Content-Type: audio/mpeg
Last-Modified: Tue, 29 Mar 2011
16:27:10 GMT Content-Length: 11226282
Date: Tue, 29 Mar 2011 22:00:33 GMT
X-Varnish: 1663119465 1663112299 Age:
73 Connection: keep-alive Via: 1.1
varnish 172.17.0.138 X-Cache: HIT

More information on "Accept-Ranges: bytes" can be found in section 14.5 here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

File resume is not supported for this HTTP request as this HTTP request is not being served by Apache, but via the caching Varnish servers within our Media Accelerator cluster. File resume is supported by Apache inherently. A list of files cached within our systems by our Varnish servers as well as more information on our Media Accelerator can be found here: http://cloudsites.rackspacecloud.com/index.php/What_is_the_Media_Accelerator_(MA)%3F

HTTP requests are only routed to the Media Accelerator when the HTTP request ends in one of these file extensions. If a query string is added to the end of the URL or if the URL is made to a different file extension, then the HTTP request is served by Apache as can be seen from the following two sets of headers:

$ curl -I
'http://flex.ekk360.com/judas-and-pilate.mp3?1'
HTTP/1.1 200 OK Server: Apache/2.2
Content-Type: audio/mpeg Date: Tue, 29
Mar 2011 21:41:56 GMT Accept-Ranges:
bytes Connection: Keep-Alive
Set-Cookie:
X-Mapping-hpadogcb=018693E96D995C67FDE4A82FC7761170;
path=/ Last-Modified: Tue, 29 Mar 2011
16:27:10 GMT Content-Length: 11226282

$ curl -I
'http://flex.ekk360.com/judas-and-pilate.mp_'
HTTP/1.1 404 Not Found Server:
Apache/2.2 Content-Type: text/html;
charset=iso-8859-1 Date: Tue, 29 Mar
2011 22:12:29 GMT Transfer-Encoding:
chunked Connection: Keep-Alive
Set-Cookie:
X-Mapping-hpadogcb=381D7664F27DBFFB6452A51D70DEDB28;
path=/

In order for this file to be streamed properly from our servers, the Media Accelerator must be bypassed by having the device either use a URL such as "http://flex.ekk360.com/judas-and-pilate.mp3?1" or by renaming the file and adding a custom mime type to your site so that the device opens the file with the media player. An alternative would be to host the file through a CDN such as Cloud Files or Amazon S3.

La differenza dovrebbe essere un file statico con una lunghezza del contenuto definita, rispetto a un flusso di shoutcast o un server che non ha offerto una lunghezza del contenuto con un file.

Se il giocatore non sa quanto è grande un file, non può recuperare la fine per raccogliere i metadati (in particolare, la durata della canzone) e presentare lo scrubber per la ricerca.

[modifica]
Uscita intestazione cURL:

$ curl -I "http://demo.ekklesia360.com/judas-and-pilate.mp3"
HTTP/1.1 200 OK
Date: Tue, 29 Mar 2011 21:59:15 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Tue, 29 Mar 2011 16:25:33 GMT
ETag: "8b30001-ab4caa-49fa182643940"
Accept-Ranges: bytes
Content-Length: 11226282
Connection: close
Content-Type: audio/mpeg

$ curl -I "http://flex.ekk360.com/judas-and-pilate.mp3"
HTTP/1.1 200 OK
Server: Apache/2.2
Content-Type: audio/mpeg
Last-Modified: Tue, 29 Mar 2011 16:27:10 GMT
Content-Length: 11226282
Date: Tue, 29 Mar 2011 21:59:20 GMT
Age: 0
Connection: keep-alive
Via: 1.1 varnish 172.17.0.138

Sul secondo file (tramite flex), noto una mancanza di "Accept-Ranges" e un tipo "Connessione" di "keep-alive".

Questo mi dice che;
(1) che Safari (/ QuickTime?) Probabilmente non emetterà una richiesta di intervallo di byte per la fine del file per leggere i dati ID3, oppure;
(2) Non c'è nessuno scrubber perché "Connection: keep-alive" significa che i nuovi dati potrebbero cadere lungo la pipe, quindi tieni il socket aperto per riceverlo in qualsiasi momento.