HTTP Examples

From Media Fragments Working Group Wiki
Jump to: navigation, search

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.

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.