HTML5 Audio Player makes multiple GET requests when loading. Why?
I have been working on a jquery plugin that uses a HTML5 audio player () to play back mp3's. I noticed that in various browsers multiple GET requests were made for the same MP3 file when the audio player was loaded.
I created a simple standalone HTML file to test this out.
<html>
<head></head>
<body>
<audio controls src="http://localhost:5000/files/one.mp3" type="audio/mp3"></audio>
<body>
<html>
When opening the page in OS X Safari 5.0.1, I saw the following logs from my web server (3 GET requests):
>> Thin web server (v1.2.7 codename No Hup)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:5000, CTRL+C to stop
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0022
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0012
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0010
Note, the requests are for "GET /one.mp3" and not "GET /files/one.mp3" because my Thin web server is running off a prefix of /files.
When opening the same HTML file in OS X Chrome, I saw 2 GET requests for /one.mp3.
When opening the same HTML file in OS X Opera, I saw 1 GET request for /one.mp3.
What is the reason for the multiple GET requests for 开发者_运维知识库a single files? The bandwidth on my server is limited and I throttle connections at 75KB/s (thats HTTP connection, not user). My worry is if Safari is making 3 HTTP connections to download (stream) a single mp3 file, it will reduce the number of concurrent users my server can handle.
Is this something I should be worried about in terms of performance/bandwidth? Also, I am curious as to why certain browsers make multiple requests for the same file, while other do not.
In the case of Firefox, three requests are made for audio. This is to support playback regions and seeking of media files that aren't downloaded yet. It's essentially downloading the file and determining it's duration in three chunks. The following was given as an explanation when this behavior was reported to Mozilla as a bug:
- The first GET reads the first chunk of the ogg file. From this we can ensure it's a valid ogg etc. The data downloaded should be cached by Firefox.
- The second GET: Unfortunately Ogg files don't contain their duration, so we terminate the initial download, and we seek to the end of the Ogg file and read a bit of data to extract the time duration of the media.
- The third GET: After we've ascertained the duration of the media, we'll resume download of the media. We don't need to redownload data which is already cached, so we resume from wherever the previous download stopped.
Though this explanation only applies to Firefox, you can presume that similar methods are used by webkit browsers as well.
I don't think you should be concerned about this affecting the number of concurrent users. If your server logs showed the timestamp in milliseconds you would see that the three requests fire consecutively and that each request is cancelled before a subsequent request is made.
Is it possible that Safari is making additional requests to fetch metadata? Try different values of the preload attribute to see if it makes any difference:
- preload="none" - no data is prefetched (shouldn't see any GETs)
- preload="metadata" - basic metadata like duration, bit rate, sample rate, etc. is prefetched (should see one GET)
- preload="auto" - the whole file is prefetched (may see multiple GETs)
See http://dev.w3.org/html5/spec/Overview.html#attr-media-preload for a full description of this attribute.
加载中,请稍侯......
精彩评论