# nginx-Range header-proxy cache- potential patch

**URL:** <https://www.ruby-forum.com/t/nginx-range-header-proxy-cache-potential-patch/219281>\
**Category:** NGINX\
**Created:** [April 26, 2012, 3:24pm UTC](https://www.ruby-forum.com/t/nginx-range-header-proxy-cache-potential-patch/219281 "2012-04-26T15:24:47Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [April 26, 2012, 3:24pm UTC](https://www.ruby-forum.com/t/nginx-range-header-proxy-cache-potential-patch/219281/1 "2012-04-26T15:24:47Z")

</div>

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:

> **[nginx & Range header & proxy cache](https://forum.nginx.org/read.php?2,215141,215141#msg-215141)**
>
> Hi If a Range request is sent to nginx proxy (e.g. header "Range: bytes=50-") and the file isn't in cache yet (cache MISS), the range is ignored and full file sent When the file has been cached (cache HIT), Range request works as expected...

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” ([Re: nginx & Range header & proxy cache](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

> **[nginx discovery journey](http://www.nginx-discovery.com)**
>
> This is the blog about my journey discovering nginx. I wanted this to be a chronological log of my progress, just like a captain's log (hello Star Trek fan's ;)).

---

<div class="post-metadata">

**Author:** ![Antoine\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a183cd/32.png) [@Antoine\_B](https://www.ruby-forum.com/u/Antoine_B)\
**Post date:** [April 26, 2012, 4:15pm UTC](https://www.ruby-forum.com/t/nginx-range-header-proxy-cache-potential-patch/219281/2 "2012-04-26T16:15:41Z")

</div>

Hello!

On Thu, Apr 26, 2012 at 03:23:53PM +0200, Antoine B. wrote:

> full answer.  
> Now, to the question “Is this intended behavior”, Maxim Dounim said  
> 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](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)

Maxim D.

---

<div class="post-metadata">

**Author:** ![Antoine\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a183cd/32.png) [@Antoine\_B](https://www.ruby-forum.com/u/Antoine_B)\
**Post date:** [April 26, 2012, 4:49pm UTC](https://www.ruby-forum.com/t/nginx-range-header-proxy-cache-potential-patch/219281/3 "2012-04-26T16:49:51Z")

</div>

Hello!

On Thu, Apr 26, 2012 at 4:15 PM, Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> > Cotnent-Length and Content-Range).  
> > allows ranges in all cases when the length of the response from  
> > [http://trac.nginx.org/nginx/changeset/4468/nginx](http://trac.nginx.org/nginx/changeset/4468/nginx)  
> > diff --git a/src/http/ngx\_http\_upstream.c b/src/http/ngx\_http\_upstream.c
> 
> - }
> 
> #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.

---

<div class="post-metadata">

**Author:** ![Antoine\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a183cd/32.png) [@Antoine\_B](https://www.ruby-forum.com/u/Antoine_B)\
**Post date:** [April 30, 2012, 6:30pm UTC](https://www.ruby-forum.com/t/nginx-range-header-proxy-cache-potential-patch/219281/4 "2012-04-30T18:30:56Z")

</div>

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 B.