Sample http range request session

Question

Is it possible to show me a sample http session with range requests. I mean what would be the request and response headers?

A few months ago the new version of the HTTP/1.1 standard was published. It has a special RFC for range requests, this is a lot more readable than the old spec, including examples for many items: https://tools.ietf.org/html/rfc7233 — Thirler, Feb 23 '15 at 11:38

score 144 · Accepted Answer · answered Dec 14 '11 at 16:27

The following exchange is between Chrome and a static web server, retrieving an MP4 video.

Initial request - for the video. Note the Accept-Ranges response header to indicate the server has range header support:

GET /BigBuckBunny_320x180.mp4
        Cache-Control: max-age=0
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range:
        Accept: text/html,application/xhtml+xml,application/xml,*/*
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Accept-Encoding: gzip,deflate,sdch
        Accept-Charset: ISO-8859-1,utf-8,*
200 OK
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 64657027
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:24 GMT

Range header in previous response detected - subsequent request with open-ended range to confirm support. Response returns a 206 status and Content-Range header to indicate the bytes present in the response body:

GET /BigBuckBunny_320x180.mp4
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range: bytes=0-
        Accept: */*
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Referer: http://localhost:8080/BigBuckBunny_320x180.mp4
        Accept-Encoding: identity
        Accept-Charset: ISO-8859-1,utf-8,*
206 Partial Content
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 64657027
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:25 GMT
        Content-Range: bytes 0-64657026/64657027

Subsequent range request to capture the end of the file (probably to capture trailing metadata):

GET /BigBuckBunny_320x180.mp4
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range: bytes=64312833-64657026
        Accept: */*
        If-Range: A023EF02BD589BC472A2D6774EAE3C58
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Referer: http://localhost:8080/BigBuckBunny_320x180.mp4
        Accept-Encoding: identity
        Accept-Charset: ISO-8859-1,utf-8,*
206 Partial Content
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 344194
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:25 GMT
        Content-Range: bytes 64312833-64657026/64657027

User clicks in the video progress bar beyond the downloaded range - a range request is issued to begin playing from the selected position:

GET /BigBuckBunny_320x180.mp4
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range: bytes=1073152-64313343
        Accept: */*
        If-Range: A023EF02BD589BC472A2D6774EAE3C58
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Referer: http://localhost:8080/BigBuckBunny_320x180.mp4
        Accept-Encoding: identity
        Accept-Charset: ISO-8859-1,utf-8,*
206 Partial Content
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 63240192
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:25 GMT
        Content-Range: bytes 1073152-64313343/64657027

Is the blank Transfer-Encoding header an artefact of the way the HTTP communication was captured or is there a real HTTP server out there generating blank values for this header? — swl10, Jul 18 '14 at 08:58
In the first case, it looks like the server is returning 64657027 bytes of content. So what's happening--is the client just throwing away that content, and then subsequently issuing a range request for the parts really wants? Or is the server not returning any content becasue something in the client's message says don't do that. If so, what is it? — Morrie, Mar 30 '15 at 15:59
@Morrie - it seems like the server, knowing that itself supports range requests, tells the client "I accept range requests" via the `Accept-Ranges: bytes` header, but it also sends down the content length for the resource so the client can make range requests with an upper bound. Nothing in the client message says do this as far as I am aware - the server can choose to respond with "here is the entire resource" or "I accept range requests" - which again is the existence of the `Accept-Ranges` header. That is my understanding of it anyway. — Simon Whitehead, Jun 14 '15 at 23:13
But doesn't the Content-Length of 64657027 in the first response mean that there are actually that many bytes of payload following the header, which the client must consume because the connection is Keep-Alive? I'm wondering what in that response message says that there is not actually any payload. — Morrie, Jun 23 '15 at 19:05
@Morrie Keep-alive is a request from the client and the client doesn't have any obligation to keep using the connection. I've just concluded in my own work that, at least for chrome, the first GET request with range "0-" is promptly aborted as soon as the header is received, instead of using a HEAD request. I believe that it's a way to avoid problems with any server that may not implement the HEAD verb correctly. — Zoomulator, Sep 10 '15 at 09:45
@Zoomulator - thats a very good explanation. Do you have any capture etc to illustrate this? If so it would be worth adding as an extra answer, for sure. — Mick, Oct 08 '15 at 13:50

Sample http range request session

1 Answers1

Linked