reverse proxy + caching seems to break range requests

[Vinay Y S]

I see this in the ngx_http_upstream.c
3481     if (r->cached) {
3482         r->allow_ranges = 1;
3483         return NGX_OK;
3484
3485     }

This seems to explain my observation of ranges working for cache-hits but
not for cache-misses. Can't we allow ranges to work even for cache-misses?

This becomes very important for configurations where caching is enabled or
disabled by the upstream by using X-accel-expires header typically based on
size of the response, like don't cache larger files. And we especially need
Range mechanism to work for larger files because they are typically file
downloads for which pause/resume or download accelerator case makes lot of
sense.

Has anyone else faced this problem? Any fix/workaround for this problem?

Thanks,
Vinay


On Tue, Apr 6, 2010 at 2:13 AM, Vinay Y S <vinay.ys at gmail.com> wrote:

> On Mon, Apr 5, 2010 at 2:46 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
>
>> Hello!
>>
>> On Sun, Apr 04, 2010 at 11:23:32PM +0530, Vinay Y S wrote:
>>
>> > Hi,
>> > I've configured nginx to run as a http reverse proxy with caching turned
>> on
>> > for a location. The backend server supports range headers and responds
>> > correctly with 206 partial content response. This is needed to support
>> > pause/resume functionality in the browsers and download managers and
>> also to
>> > support download accelerator clients.
>> >
>> > But with nginx reverse proxy with caching enabled, it seems to not work.
>> > nginx returns full response even when range header is present. Is this a
>> > known issue?
>> > Please help fix this.
>>
>> nginx removes Range header (as well as several other headers)
>> before passing request to upstream to make sure full response will
>> be cached and other requests for the same uri will be served
>> correctly.
>>
>>  It's fine for it send full request to the upstream so that it can cache
> the full response. Actually range requests and 206 responses work correctly
> when caching is not enabled. So, even when caching is enabled, it can still
> respond correctly to the client by obeying the range header, isn't it? Is
> this not implemented consciously for some reason?
>
> Thanks,
> --
> Vinay
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20100406/a3246cdb/attachment.html>