Warning:
This wiki has been archived and is now read-only.
HTTP Examples
This page gives some examples of the HTTP transactions involved for retrieving media fragments. We begin with some basic examples, then use various combinations involving Time Range units and HTTP Range Refer. For each example, we provide a description of UA and server behavior if any of the required methods are not supported. The purpose is to show how more complex examples fall back gracefully to the behavior of the simpler examples if these features are not available.
Contents
Basic examples
Query URI
This first example uses none of the extra techniques.
Given the URI http://www.example.com/video.ogv?t=00:10,00:20, the User Agent issues the following request:
GET /video.ogv?t=00:10,00:20 HTTP/1.1
The server responds with:
HTTP 200 OK Content-Length: 1000 ...
Failure and fallback
If the UA has constructed this URL (ie. it is not following a link), then it is possible that it does not refer to a segment of video. In this case the server response is implementation dependent, eg. it may server the entire resource, as though http://www.example.com/video.ogv had been requested:
HTTP 200 OK Content-Length: 1000000
Or it may explicitly respond that the requested URI is not exist:
HTTP 404 Not Found
Fragment URI
This example retrieves the same data, using Server-parsed Fragments.
Given the URI http://www.example.com/video.ogv#t=00:10,00:20, a User Agent that supports server-parsed fragments issues the following request:
GET /video.ogv HTTP/1.1 Fragment: t=00:10%2C00:20
A server that supports server-parsed fragments responds with:
HTTP 200 OK Content-Length: 1000 Content-Fragment: t=00:10%2C00:20 Vary: Fragment ...
The body of this response is the same as for the Query URI example.
Failure and fallback
- A User Agent that does not support server-parsed fragments will simply remove the URI fragment and issue the request:
GET /video.ogv HTTP/1.1
To which any HTTP server will respond with the entire resource.
- A server that does not support server-parsed fragments will ignore any Fragment: request header, and respond with the entire resource.
Conversion of Fragment to Range
A User Agent that can play sequences of media knowing only the time ranges of the intervals MAY strip the time specification from a media fragment, and convert this into an HTTP Range request header.
Time Fragment URI
Given the URI http://www.example.com/video.ogv#t=00:10,00:20, a User Agent that supports both server-parsed fragments and time ranges issues the following request:
GET /video.ogv HTTP/1.1 Range: npt=00:10-00:20
A server that supports time ranges responds with:
HTTP 200 OK Content-Length: 1000 Content-Range: time:npt=00:10-00:20 ...
Failure and fallback
- A User Agent that does not support server-parsed fragments will simply remove the URI fragment and issue the request:
GET /video.ogv HTTP/1.1
To which any HTTP server will respond with the entire resource.
- A User-Agent that supports server-parsed fragments, but not time ranges, will issue the request:
GET /video.ogv HTTP/1.1 Fragment: t=00:10%2C00:20
to which the server will respond (or fail) as for the Fragment example above.
- A server that does not support time ranges will respond to a "Range: time=..." request with:
416 Requested Range Not Satisfiable
Track+Time Fragment URI
In the case of a Fragment that contains both time and some other identifier such as track, only the time can be converted to a Range request header. The track specifier MUST be requested using the Fragment request header.
Given the URI http://www.example.com/video.ogv#track=audio&t=00:10,00:20, a User Agent that supports both server-parsed fragments and time ranges issues the following request:
GET /video.ogv HTTP/1.1 Range: npt=00:10-00:20 Fragment: track=audio
A server that supports both server-parsed fragments and time ranges responds with:
HTTP 200 OK Content-Length: 600 Content-Range: time:npt 00:10-00:20 Content-Fragment: track=audio Vary: Fragment ...
Failure and fallback
- A User Agent that does not support server-parsed fragments will simply remove the URI fragment and issue the request:
GET /video.ogv HTTP/1.1
To which any HTTP server will respond with the entire resource.
- A User-Agent that supports server-parsed fragments, but not time ranges, will issue the request:
GET /video.ogv HTTP/1.1 Fragment: track=audio&t=00:10%2C00:20
to which the server will respond (or fail) as for the Fragment example above.
- A server that does not support time ranges will respond to a "Range: time=..." request with:
416 Requested Range Not Satisfiable
Examples with Range-Refer
The Range-Refer mechanism improves the cacheability of responses.
Query URI + Range-Refer: bytes
We begin with a simple example using only Range-Refer.
Given the URI http://www.example.com/video.ogv?t=00:10,00:20, a User Agent that supports "Range-Refer: bytes" issues the following request:
GET /video.ogv?t=00:10,00:20 HTTP/1.1 Accept-Range-Refer: bytes
A server that supports "Range-Refer: bytes" responds with:
HTTP 200 OK Content-Length: 1000 Vary: Accept-Range-Refer Range-Refer: this bytes 0-1000, http://www.example.com/video.ogv bytes 40000-60000 ...
The client then takes bytes 0-1000 of the body of this response, and issues an HTTP range request to http://www.example.com/ for the referred range. Note that this is a normal HTTP/1.1 request, and need not be to a server supporting Range-Refer:
GET /video.ogv HTTP/1.1 Range: bytes=40000-60000
A server supporting byte ranges at http://www.example.com/ responds with:
HTTP 206 Partial Content Content-Length: 20000 Vary: Accept-Range-Refer Content-Range: bytes=40000-60000/100000 ...
Failure and fallback
- A UA that does not support "Range-Refer: bytes" will simply issue the request:
GET /video.ogv?t=00:10,00:20 HTTP/1.1
and the server will respond as for the first Query example above.
- A server that does not support "Range-Refer: bytes" will simply ignore the Accept-Range-Refer request header, and respond or fail as for the Query example above, eg:
HTTP 200 OK Content-Length: 10000
Fragment URI + Range-Refer: bytes
We now show how Media Fragments and Range-Refer can be used together.
Given the URI http://www.example.com/video.ogv#t=00:10,00:20, a User Agent that supports both server-parsed fragments and "Range-Refer: bytes" issues the following request:
GET /video.ogv HTTP/1.1 Fragment: t=00:10%2C00:20 Accept-Range-Refer: bytes
A server that supports both server-parsed fragments and "Range-Refer: bytes" responds with:
HTTP 200 OK Content-Length: 1000 Content-Fragment: t=00:10%2C00:20 Vary: Fragment, Accept-Range-Refer Range-Refer: this bytes 0-1000, http://www.example.com/video.ogv bytes 40000-60000 ...
The client then takes bytes 0-1000 of the body of this response, and issues an HTTP range request to http://www.example.com/ for the referred range. Note that this a normal HTTP/1.1 request,and need not be to a server supporting Range-Refer:
GET /video.ogv HTTP/1.1 Range: bytes=40000-60000
A server supporting byte ranges at http://www.example.com/ responds with:
HTTP 206 Partial Content Content-Length: 20000 Vary: Fragment, Accept-Range-Refer Content-Range: bytes=40000-60000/100000 ...
This response does not invalidate cached data from the previous response, as the previous one included "Vary: Fragment".
Failure and fallback
- A User Agent that does not support server-parsed fragments will simply remove the URI fragment and issue the request:
GET /video.ogv HTTP/1.1
To which any HTTP server will respond with the entire resource.
- A UA that supports server-parsed fragments but does not support "Range-Refer: bytes" will simply issue the request:
GET /video.ogv HTTP/1.1 Fragment: t=00:10%2C00:20
to which the server will respond (or fail) as for the Fragment example above.
- A server that does not support "Range-Refer: bytes" will simply ignore the Accept-Range-Refer request header, and
respond (or fail) as for the Fragment example above.
Query URI + Range-Refer: time
Here is an example using Range-Refer with the new Range units of time.
Given the URI http://www.example.com/video.ogv?t=00:10,00:20, a User Agent that supports "Range-Refer: time" issues the following request:
GET /video.ogv?t=00:10,00:20 HTTP/1.1 Accept-Range-Refer: npt
A server that supports "Range-Refer: time" responds with:
HTTP 200 OK Content-Length: 1000 Vary: Accept-Range-Refer Range-Refer: this npt 00:00-00:10, http://www.example.com/video.ogv time 00:10-00:20 ...
The client then uses the body of this response to decode time 00:00-00:10, and issues an HTTP range request to http://www.example.com/ for the referred range. Note that this a normal HTTP/1.1 request using the time range units, and need not be to a server supporting Range-Refer:
GET /video.ogv HTTP/1.1 Range: npt=00:10-00:20
The server at http://www.example.com/ responds with:
HTTP 206 Partial Content Content-Length: 20000 Vary: Accept-Range-Refer Content-Range: time:npt 00:10-00:20/01:20 ...
Failure and fallback
- A UA that does not support "Range-Refer: time" will simply issue the request:
GET /video.ogv?t=00:10,00:20 HTTP/1.1
and the server will respond as for the first Query example above.
- A server that does not support "Range-Refer: time" will simply ignore the Accept-Range-Refer request header, and respond or fail as for the Query example above, eg:
HTTP 200 OK Content-Length: 10000
Fragment URI + Range-Refer: time
And the same request using Media Fragment URI.
Given the URI http://www.example.com/video.ogv#t=00:10,00:20, a User Agent that supports both server-parsed fragments and "Range-Refer: time" issues the following request:
GET /video.ogv HTTP/1.1 Fragment: t=00:10%2C00:20 Accept-Range-Refer: npt ...
A server that supports both server-parsed fragments and "Range-Refer: time" responds with:
HTTP 200 OK Content-Length: 1000 Content-Fragment: t=00:10%2C00:20 Vary: Fragment, Accept-Range-Refer Range-Refer: this npt 00:00-00:10, http://www.example.com/video.ogv time 00:10-00:20 ...
The client then uses the body of this response to decode time 00:00-00:10, and issues an HTTP range request to http://www.example.com/ for the referred range. Note that this is a normal HTTP/1.1 request using the time range units, and need not be to a server supporting Range-Refer:
GET /video.ogv HTTP/1.1 Range: npt=00:10-00:20
The server at http://www.example.com/ responds with:
HTTP 206 Partial Content Content-Length: 20000 Vary: Fragment, Accept-Range-Refer Content-Range: time:npt 00:10-00:20/01:20 ...
Failure and fallback
- A User Agent that does not support server-parsed fragments will simply remove the URI fragment and issue the request:
GET /video.ogv HTTP/1.1
To which any HTTP server will respond with the entire resource.
- A UA that supports server-parsed fragments but does not support "Range-Refer: time" will simply issue the request:
GET /video.ogv HTTP/1.1 Fragment: t=00:10%2C00:20
to which the server will respond (or fail) as for the Fragment example above.
- A server that does not support "Range-Refer: time" will simply ignore the Accept-Range-Refer request header, and
respond (or fail) as for the Fragment example above.
Track+Time Fragment URI + Range-Refer: bytes
This example uses a fragment specifying both time and track. The time is converted into a Range request header, and the User Agent can accept a response using Range-Refer.
Given the URI http://www.example.com/video.ogv#track=audio&t=00:10,00:20, a User Agent that supports server-parsed fragments, time ranges and "Range-Refer: bytes" issues the following request:
GET /video.ogv HTTP/1.1 Fragment: track=audio Range: npt=00:10-00:20 Accept-Range-Refer: bytes
A server that supports server-parsed fragments, time ranges and "Range-Refer: bytes" responds with:
HTTP 200 OK Content-Length: 600 Content-Range: npt 00:10-00:20/01:20 Content-Fragment: track=audio Vary: Fragment, Accept-Range-Refer Range-Refer: this bytes 0-600, http://www.example.com/video.ogv#track=audio bytes 20000-30000 ...
The client then takes bytes 0-600 of the body of this response, and issues an HTTP range request to http://www.example.com/ for the referred range. Note that this is a normal HTTP/1.1 request,and need not be to a server supporting Range-Refer:
GET /video.ogv HTTP/1.1 Fragment: track=audio Range: bytes=20000-30000
A server supporting server-parsed fragments and byte ranges at http://www.example.com/ responds with:
HTTP 206 Partial Content Content-Length: 10000 Vary: Fragment, Accept-Range-Refer Content-Range: bytes=20000-30000/50000 Content-Fragment: track=audio ...
Failure and fallback
- A User Agent that does not support server-parsed fragments will simply remove the URI fragment and issue the request:
GET /video.ogv HTTP/1.1
To which any HTTP server will respond with the entire resource.
- A UA that supports server-parsed fragments but does not support time ranges or "Range-Refer: bytes" will simply issue the request:
GET /video.ogv HTTP/1.1 Fragment: track=audio&t=00:10%2C00:20
to which the server will respond (or fail) as for the Fragment example above.
- A UA that supports server-parsed fragments and "Range-Refer: bytes" but does not support time ranges will simply issue the request:
GET /video.ogv HTTP/1.1 Fragment: track=audio&t=00:10%2C00:20 Accept-Range-Refer: bytes
to which the server will respond (or fail) as for the "Fragment URI + Range-Refer: bytes" example above.
- A server that does not support "Range-Refer: time" will simply ignore the Accept-Range-Refer request header, and respond (or fail) as for the "Track+Time Fragment URI" example above.