0

Let's say a client makes a request like the following (pulled from iOS):

GET /test.mp4 HTTP/1.1
Host: example.com:80
Range: bytes=0-1
X-Playback-Session-Id: 3DFA3BE3-CB22-4EC5-808F-B59A735DCECE
Accept-Encoding: identity
Accept: */*
Accept-Language: en-us
Connection: keep-alive
User-Agent: AppleCoreMedia/1.0.0.11B554a (iPad; U; CPU OS 7_0_4 like Mac OS X; en_us)

There other such requests out there, I believe Chrome might test the waters by asking for blank Range.

How can the server respond to any such request so that it does not need to honor Range , but rather treat it as a standard HTTP delivery, and the client will play the file?

Sending a regular header response and the data as though the client were not asking for Range does not seem to work.

EDIT: Conversely, if the client does not request a Range, is it okay to respond with HTTP 206 with full filesize in Content-Length and also Content-Range header (which client will ignore)?

davidkomer
  • 3,020
  • 2
  • 23
  • 58

2 Answers2

1

If the server does not support the Range header, it would send a normal 200 reply to send the entire file. If the server supports the Range header, it would send a 206 or 416 reply, depending on whether the requested range can be satisfied or not. This is covered in RFC 2616 Section 14.35.

It is not OK to respond with 206 if the client did not request a Range.

Community
  • 1
  • 1
Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • What's strange is that when I try this to serve an mp4 to iOS, it fails. Is it acceptable that a client will *require* a server to satisfy Range requests? – davidkomer Jan 24 '14 at 08:04
0

Try responding with HTTP 1.0 - it doesn't support range requests at all.

Maybe the client will treat such a reply more gracefully.

Mike Richardson
  • 1
  • 2