nginx-Range header-proxy cache- potential patch

[Antoine Bonavita]

Hello!

On Thu, Apr 26, 2012 at 4:15 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
>
> On Thu, Apr 26, 2012 at 03:23:53PM +0200, Antoine Bonavita wrote:
>
>> 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.
>
> I've recently committed the patch which makes it (almost) safe to
> just set allow_ranges on proxied replies, see
>
> http://trac.nginx.org/nginx/changeset/4468/nginx
>
> Remaining issues are with multiple ranges requests (which aren't
> really used by anyone in real life except Adobe Acrobat).  As long
> as there are no such requests in your environment (or you are
> using max_ranges 1; anyway), you may try the following patch:
>
> # HG changeset patch
> # Parent 8a7ee0318b175b8d76275c5d34707eb52b276188
> Upstream: allow ranges for cacheable replies.
>
> diff --git a/src/http/ngx_http_upstream.c b/src/http/ngx_http_upstream.c
> --- a/src/http/ngx_http_upstream.c
> +++ b/src/http/ngx_http_upstream.c
> @@ -3680,10 +3680,9 @@ ngx_http_upstream_copy_allow_ranges(ngx_
>
>  #if (NGX_HTTP_CACHE)
>
> -    if (r->cached) {
> +    if (r->cached || r->upstream->cacheable) {
>         r->allow_ranges = 1;
>         return NGX_OK;
> -
>     }
>
>  #endif
>
>
> (it's a bit old, but should apply cleanly)
As usual you rock: it applies cleanly on 1.2.0 and solves my problem.
I've been testing on my machine for now. I'll release it to production
beginning of next week and let you know.

Thanks a lot,

A.

>
> Maxim Dounin
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx