Is it possible to show me a sample http session with range requests. I mean what would be the request and response headers?
Sample http range request session
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: tools.ietf.org/html/rfc7233 –
Ocarina
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? –
Ashford
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? –
Jackelinejackelyn
@Jackelinejackelyn - 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. –
Selfeducated 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. –
Jackelinejackelyn
@Jackelinejackelyn 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. –
Hillary
@Hillary - 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. –
Fra
You have an invalid etag in the example. –
Eyas
@JulianReschke Hi Julian, what is invalid about it? –
Magnetics
@Magnetics it needs to be quoted –
Eyas
© 2022 - 2024 — McMap. All rights reserved.