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