nginx-Range header-proxy cache- potential patch

Antoine Bonavita antoine.bonavita at gmail.com
Thu Apr 26 13:23:53 UTC 2012


Hello,

I'm currently using nginx to serve "small" video files (<2MB) to
mobile devices. The way I set it up is as follow:
2 nginx servers reverse proxying with cache
1 upstream server where the files are actually uploaded

It's all working fine except that the iPhones seem to have the habit
of always doing range requests with range 0-1 first when they are
about to play a video. And they really don't like it when they get the
full answer.

Now, the problem I'm facing is the one described here:
http://forum.nginx.org/read.php?2,215141,215141#msg-215141

Which can be summed up as:
- If file in cache: range header honored (206, appropriate
Cotnent-Length and Content-Range).
- If file not in cache: server ignores the range header and sends the
full file (200 and Content-Length set to full file size).

Now, to the question "Is this intended behavior", Maxim Dounim said
"yes" (http://forum.nginx.org/read.php?2,215141,215142#msg-215142)

I looked at the code and there is a flag on request : r->allow_ranges.

>From what I can tell, it is set to false in most cases, except in the
ngx_http_static_module. I would be happy to work on a patch that
allows ranges in all cases when the length  of the response from
upstream is known (ie not when upstream response uses chunked
encoding).

But before I start working on this I would really appreciate if one of
the gurus here could tell me whether I'm opening a Pandora box or not.
And what I should be careful with.

Thanks a lot,

Antoine.

--
Looks like I'm resuming my journey in nginx land at last
http://www.nginx-discovery.com



More information about the nginx mailing list