nginx-Range header-proxy cache- potential patch

[Antoine Bonavita]

Hello,

Just a quick update as promised: I applied Maxim patch on 1.2.0 and
deployed on my production servers today.
Everything is smooth and the original problem fixed.

Thanks again,

Antoine.

On Thu, Apr 26, 2012 at 4:49 PM, Antoine Bonavita
<antoine.bonavita at gmail.com> wrote:
> 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