nginx-Range header-proxy cache- potential patch

Server NGINX
1

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:

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)

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

2

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

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.

3

Hello!

On Thu, Apr 26, 2012 at 4:15 PM, Maxim D. [email protected]
wrote:

Cotnent-Length and Content-Range).
allows ranges in all cases when the length of the response from
Changeset 4468:93dd50a9dc70 – 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.

4

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.