Byte-range request not possible for proxy_cache if origin doesn't return accept-ranges header

Lucas Rolff lucas at lucasrolff.com
Wed Nov 14 14:36:10 UTC 2018


Hi guys,

I've been investigating why byte-range requests didn't work for files that are cached in nginx with proxy_cache, I'd simply do something like:

$ curl -r 0-1023 https://cdn.domain.com/mymovie.mp4

What would happen was that the full length of a file would be returned, despite being in the cache already (I know that the initial request, you can't seek into a file).

Now, after investigation, I compared it with another file that I knew worked fine, I looked in the file on disk, the only difference between the two files, was the fact that one cached file contained Accept-Ranges: bytes, and another didn't have it.

Investigating this, I tried to add the header Accept-Ranges: bytes on an origin server, and everything started to work from nginx as well.

Now, I understand that Accept-Ranges: bytes should be sent whenever a server supports byte-range requests.
I'd expect that after nginx has fetched the full file, that it would be perfectly capable of doing byte-range requests itself, but it seems like it's not a possibility.

I'm not really sure if this is a bug or not, but I do find it odd that the behavior is something like: "If origin does not understand byte-range requests, then I also shouldn't understand them".

Is there a way to solve this on the nginx side directly to "fix" origin servers that do not send an Accept-Ranges header, or is it something that could possibly be fixed in such a way that nginx doesn't "require" the cached file to contain the "Accept-Ranges: bytes" header, to be able to do range requests to it?

Thanks in advance!

Best Regards,
Lucas Rolff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20181114/671fda29/attachment.html>


More information about the nginx mailing list