Http header header requests the whole file

Question

I am working with C # webserver from codeplex version 1.1. I applied the Accept-Range headers and it works. However, when I use wirehark (version 1.4.1 (SVN Rev 34476 from / trunk -1.4)) to catch traffic, I see the following:

GET /movies/i_am_legend%20dvd/main.m4v HTTP/1.1 Host: 10.100.1.199:8081 Accept: */* Range: bytes=0-1 Accept-Encoding: identity Connection: keep-alive User-Agent: AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; nl_nl) X-Playback-Session-Id: 9CED81CC-BFAE-4CF6-A477-0EA62B2C652F HTTP/1.1 206 PartialContent Content-Range: bytes 0-1/652965648 Accept-Ranges: bytes ETag: "0daA8D4/wgt4MFvxdNIPLw==" Date: Wed, 13 Jun 2012 09:10:18 GMT Content-Length: 2 Content-Type: video/x-m4v Server: Tiny WebServer Connection: keep-alive .. << 2 bytes data GET /movies/i_am_legend%20dvd/main.m4v HTTP/1.1 Host: 10.100.1.199:8081 Accept: */* Range: bytes=0-652965647 Accept-Encoding: identity Connection: keep-alive User-Agent: AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; nl_nl) X-Playback-Session-Id: 9CED81CC-BFAE-4CF6-A477-0EA62B2C652F HTTP/1.1 206 PartialContent Content-Range: bytes 0-652965647/652965648 Accept-Ranges: bytes ETag: "0daA8D4/wgt4MFvxdNIPLw==" Date: Wed, 13 Jun 2012 09:10:18 GMT Content-Length: 652965648 Content-Type: video/x-m4v Server: Tiny WebServer Connection: keep-alive 

The web server will try to send the whole file (> 600 MB), wirehark shows that the whole conversation is 159774 bytes. If I do the same with IIS, I get similar headers

 GET /ipod/main.m4v HTTP/1.1 Host: 10.100.1.199 User-Agent: AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; nl_nl) Accept: */* Range: bytes=0-1 Accept-Encoding: identity X-Playback-Session-Id: C5BBF91D-78AB-42BA-ACE0-D74AB9D845CE Connection: keep-alive HTTP/1.1 206 Partial Content Content-Type: video/x-m4v Last-Modified: Mon, 11 Jun 2012 10:33:41 GMT Accept-Ranges: bytes ETag: "7243cabbd47cd1:0" Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Wed, 13 Jun 2012 09:21:03 GMT Content-Length: 2 Content-Range: bytes 0-1/652965648 .. << 2 bytes of data GET /ipod/main.m4v HTTP/1.1 Host: 10.100.1.199 User-Agent: AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; nl_nl) Accept: */* Range: bytes=0-652965647 Accept-Encoding: identity X-Playback-Session-Id: C5BBF91D-78AB-42BA-ACE0-D74AB9D845CE Connection: keep-alive HTTP/1.1 206 Partial Content Content-Type: video/x-m4v Last-Modified: Mon, 11 Jun 2012 10:33:41 GMT Accept-Ranges: bytes ETag: "7243cabbd47cd1:0" Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Wed, 13 Jun 2012 09:21:03 GMT Content-Length: 652965648 Content-Range: bytes 0-652965647/652965648 

Wireshark shows that the whole conversation is 175615 bytes.

I was looking for more information on Accept-Range headers, and so far I can only find that the server should send the requested range. But I cannot believe that it is intended to use a range query to query a huge file at a time.

My web server is trying to send the whole file because it was requested as such, but I see new range requests coming in larger ranges like this (only the range header copied from the request header ..) - hark wire time

 Range: bytes=2162688-652965647 (@ time == 1.646204) Range: bytes=4980736-652965647 (@ time == 2.754322) Range: bytes=6356992-652965647 (@ time == 2.922479) 

After reading this, I tried to send a shorter range whenever I receive a range request for the entire file. But then it does not work at all.

I would like to know:

• Is the range request for the whole file some kind of bug in iOS (see also 4.3.3), I would expect Range: bytes=0-1 and after replaying something like Range: bytes=0-65535/652965648
• Can I somehow elegantly refuse this large request and tell the requested one that I can deliver the maximum size right away? (I did not find this in the RFC)
• Is IIS just aborting this request after a certain number of bytes?

EDIT : for number 3: not IIS, but the browser seems to just terminate (and close) the connection. After that, a new request is created. I cannot imagine that a range request was requesting the entire file or the HUGE parts of the file.

EDIT . In iOS7, it seems to have changed. The first range request remains the same (bytes 0-1). After that, I see 2 or 3 range requests, as mentioned above, where the last request continues to transmit bytes for a longer period. However, several queries are still being performed.

Answer 1

• Is the range request for the whole file a kind of mistake in iOS (I saw it also with 4.3.3), I would expect Range: bytes = 0-1 and after replaying something like Range: bytes = 0 -65535/652965648

I do not know if this is a mistake. However, I can think of the reasons why the media player requests the entire file in one request. Thus, the media player receives a data stream from which it can read all the data from beginning to end.

Once the media player reads enough data from the stream, it can start playing the media file. He then chooses how much data he should buffer in the background during media playback. This can be several different approaches:

• Hold the entire media file. This is a good strategy when bandwidth is cheap (the user does not pay or does not pay a fixed rate for data transfer). It is assumed that the user wants to see / listen to the entire media file.

• Flax buffer is enough to avoid lag. This is a good strategy when bandwidth is expensive (user pays a byte).

  In an ideal setting, the media player will not need to accumulate anything at all and instead decode the data from the stream during real-time media playback. However, this will require that the underlying network channel be super stable and always transmit data at the required pace.

  This is not so, and therefore the media player will select a buffer for a couple of seconds or minutes ahead.

It is important to note that any strategy was chosen, but a media player might make sense to request the entire resource in one request.

However, range queries are very important for a media player if:

• The connection is interrupted (for any reason).
• The user jumps forward in the media. (for example, wants to see what 10 minutes in the movie)

The media player can then close the data stream that it originally opened and send a range request for the desired position.

2. Can I somehow elegantly refuse this large request and tell the requested one that I can deliver the maximum size right away?

No, you can’t. Range requests are initiated by the client / browser, and a server that claims to support range requests (through the Accept-Ranges header) must obey the client and respond with the entire range request.

However, you can send data with the title Transfer-Encoding: chunked . This will allow your server to control how large chunks of data it is supposed to transmit. However, it still runs through a single HTTP connection.