Forum: NGINX reverse proxy_

Hi,

I am setting up a reverse-proxy system with Nginx (0.8.32) both as 
back-end and proxy. The system is used for delivering static large 
files.

What I would like to achieve is caching the files on the proxies as long 
as possible offloading the back-end. I would also like the proxy to 
react to changes on the back-end, but without retransmitting already 
cached unmodified content.

My problem is that I'm not able to get the proxy to revalidate 
unmodified static content  without retransmitting the already cached 
file. E.g. if I set proxy_cache_valid for 200/OK delivered content to 60 
minutes the proxy won't react to changes in the back-end for that period 
of time, and if I set it to 1 minute the file will be retransmitted from 
back-end to proxy every minute, if requested from the proxy by a client. 
What I would like is, for example, for the proxy to revalidate cached 
content with I-M-S set to the time of the content being cached and if 
not modified refreshing the validity of the previously cached content 
and returning it to the client.

I've looked through the documentation and played with cache-control 
directives like for example pre/post-check without succeeding in 
creating this behaviour. There probably is an obvious answer to this 
question, only I haven't been able to find it.

Kind regards,
Fredrik Widlund

Hello!

On Tue, Feb 16, 2010 at 04:25:21PM +0100, Fredrik Widlund wrote:

> retransmitting already cached unmodified content.
> and if not modified refreshing the validity of the previously 
> cached content and returning it to the client.
> 
> I've looked through the documentation and played with 
> cache-control directives like for example pre/post-check without 
> succeeding in creating this behaviour. There probably is an 
> obvious answer to this question, only I haven't been able to 
> find it.

It's not currently supported.

Maxim Dounin

Hi Maxim,

Thanks for the answer! Are there currently any plans to add support for 
this in the near future?

Kind regards,
Fredrik Widlund

-----Ursprungligt meddelande-----
Från: Maxim Dounin [mailto:mdounin@mdounin.ru]
Skickat: den 16 februari 2010 16:58
Till: nginx@nginx.org
Ämne: Re: reverse proxy_

Hello!

On Tue, Feb 16, 2010 at 04:25:21PM +0100, Fredrik Widlund wrote:

> retransmitting already cached unmodified content.
> and if not modified refreshing the validity of the previously
> cached content and returning it to the client.
>
> I've looked through the documentation and played with
> cache-control directives like for example pre/post-check without
> succeeding in creating this behaviour. There probably is an
> obvious answer to this question, only I haven't been able to
> find it.

It's not currently supported.

Maxim Dounin

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx

On Tue, Feb 16, 2010 at 8:07 AM, Fredrik Widlund
<fredrik.widlund@qbrick.com> wrote:
>
>
> Hi Maxim,
>
> Thanks for the answer! Are there currently any plans to add support for this in the near future?
>
> Kind regards,
> Fredrik Widlund

It's not really doable as far as I understand things, at least not in
a general, portable way that satisfies all backends.

What you CAN do is you use ngx_cache_purge to have the backend inform
nginx when content has changed.  This is the only method that is
general enough for any backend, but it of course requires you to do
something.

http://labs.frickle.com/nginx_cache_purge

Good luck.

-- Merlin

Hi,

Explicitly purging the cache would not work in this scenario though.

Why is this not doable? I'm even considering adding support for this 
myself into Nginx, since we really need it and also since it seemed kind 
of natural?

This could of course be an optional feature, but it would be interesting 
to know what this breaks?

Regards,
Fredrik

On Wed, Feb 24, 2010 at 3:20 AM, Fredrik Widlund
<fredrik.widlund@qbrick.com> wrote:
> Why is this not doable? I'm even considering adding support for this myself into Nginx, since we really need it and also since it seemed kind of natural?
>
> This could of course be an optional feature, but it would be interesting to know what this breaks?

I agree... this shouldn't be impossible by any stretch. Squid seems to
handle this scenrio just fine, and the Cache-Control infrastructure of
HTTP/1.1 was designed explicitly to enable this behavior.

What is the scnario that doesn't work for this?
--
RPM

Hi Merlin,

Could you elaborate a bit around the problems with achieving this in a 
general way? It would be valuable to know before one tries to solve the 
problem as good as is possible.

Kind regards,
Fredrik Widlund