Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As <a href="https://stackoverflow.com/users/358679/wrikken">Wrikken</a> suggested, it's a valid request. It's also quite common when the client is requesting media or resuming a download. </p> <p>A client will often test to see if the server handles ranged requests other than just looking for an <code>Accept-Ranges</code> response. Chrome <em>always</em> sends a <code>Range: bytes=0-</code> with its first GET request for a video, so it's something you can't dismiss.</p> <p>Whenever a client includes <code>Range:</code> in its request, even if it's malformed, it's expecting a partial content (206) response. When you seek forward during HTML5 video playback, the browser only requests the starting point. For example:</p> <pre><code>Range: bytes=3744- </code></pre> <p>So, in order for the client to play video properly, your server must be able to handle these incomplete range requests. </p> <p>You can handle the type of 'range' you specified in your question in two ways:</p> <p>First, You could reply with the requested starting point given in the response, then the total length of the file minus one (the requested byte range is zero-indexed). For example:</p> <p>Request:</p> <pre><code>GET /BigBuckBunny_320x180.mp4 Range: bytes=100- </code></pre> <p>Response:</p> <pre><code>206 Partial Content Content-Type: video/mp4 Content-Length: 64656927 Accept-Ranges: bytes Content-Range: bytes 100-64656926/64656927 </code></pre> <p>Second, you could reply with the starting point given in the request and an open-ended file length (size). This is for webcasts or other media where the total length is unknown. For example: </p> <p>Request:</p> <pre><code>GET /BigBuckBunny_320x180.mp4 Range: bytes=100- </code></pre> <p>Response:</p> <pre><code>206 Partial Content Content-Type: video/mp4 Content-Length: 64656927 Accept-Ranges: bytes Content-Range: bytes 100-64656926/* </code></pre> <p><strong>Tips:</strong></p> <p>You must always respond with the content length included with the range. If the range is complete, with start to end, then the content length is simply the difference:</p> <p>Request: Range: bytes=500-1000</p> <p>Response: Content-Range: bytes 500-1000/123456</p> <p>Remember that the range is zero-indexed, so <code>Range: bytes=0-999</code> is actually requesting 1000 bytes, not 999, so respond with something like:</p> <pre><code>Content-Length: 1000 Content-Range: bytes 0-999/123456 </code></pre> <p>Or:</p> <pre><code>Content-Length: 1000 Content-Range: bytes 0-999/* </code></pre> <p>But, avoid the latter method if possible because some media players try to figure out the duration from the file size. If your request is for media content, which is my hunch, then you should include its duration in the response. This is done with the following format:</p> <pre><code>X-Content-Duration: 63.23 </code></pre> <p>This must be a floating point. Unlike <code>Content-Length</code>, this value doesn't have to be accurate. It's used to help the player seek around the video. If you are streaming a webcast and only have a general idea of how long it will be, it's better to include your estimated duration rather than ignore it altogether. So, for a two-hour webcast, you could include something like:</p> <pre><code>X-Content-Duration: 7200.00 </code></pre> <p>With some media types, such as webm, you must also include the content-type, such as:</p> <pre><code>Content-Type: video/webm </code></pre> <p>All of these are necessary for the media to play properly, especially in HTML5. If you don't give a duration, the player may try to figure out the duration (to allow for seeking) from its file size, but this won't be accurate. This is fine, and necessary for webcasts or live streaming, but not ideal for playback of video files. You can extract the duration using software like FFMPEG and save it in a database or even the filename.</p> <p><code>X-Content-Duration</code> is being phased out in favor of <code>Content-Duration</code>, so I'd include that too. A basic, response to a "0-" request would include at least the following:</p> <pre><code>HTTP/1.1 206 Partial Content Date: Sun, 08 May 2013 06:37:54 GMT Server: Apache/2.0.52 (Red Hat) Accept-Ranges: bytes Content-Length: 3980 Content-Range: bytes 0-3979/3980 Content-Type: video/webm X-Content-Duration: 2054.53 Content-Duration: 2054.53 </code></pre> <p>One more point: Chrome always starts its first video request with the following:</p> <pre><code>Range: bytes=0- </code></pre> <p>Some servers will send a regular 200 response as a reply, which it accepts (but with limited playback options), but try to send a 206 instead to show than your server handles ranges. <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2" rel="noreferrer">RFC 2616</a> says it's acceptable to ignore range headers.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload