HTTP Range: header and 206 Partial Content responses


#1

How does Fastly handle requests with Range headers?

Does it pass the byte-range on to the origin, or does it pull the whole object down, or does it pull a larger range down if the client requested a small range?

If Fastly pulls the whole object down, does it return the requested byte range, or the whole object?


#2

Hi Donald,

The default behavior for Fastly is to strip the range header from the request to origin. Fastly fetches the full object. If there is a partial content request, we also strip the content-range header in vcl_fetch based on the assumption we have the full object in cache and can serve based on content-length.

However, streaming-miss is an option for large files.


#3

Cassandra,

Your reply seems to indicate that enabling streaming-miss does cause Fastly to only load the requested byte ranges from the origin service, but it is unclear (and we cannot find any further documentation).

If we enable streaming-miss, is the client-requested byte range honored when making a request to the origin, or is the entire file loaded from the origin?


#4

Hi Thomas.

Streaming miss is enabled in the fetch stage of the VCL flow, which runs after headers have been received from the origin. By this point we’ve already sent the request to origin, so it’s too late for turning streaming miss on or off to make any difference to the origin request.

Fastly will by default always load full objects from origin, regardless of whether you choose to stream misses. If the request is for a range, of course only that range will be streamed, while the whole object will go into cache.