HTTP Purge support for (fastcgi|proxy)_cache

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

HTTP Purge support for (fastcgi|proxy)_cache

Johan Bergström
Hey guys (and girls)

We're using fastcgi_cache/proxy_cache quite extensively at our sites,  
and are in dire need of purging content from our cache. Explicit files  
will do in our case, but I clearly see the point of wildcards. The  
only config option I can think of (except modifying parts related to  
proxy_cache and fastcgi_cache such as proxy_cache_methods) is some  
kind of "allow_purge" ACL that is similar to the allow-directive  
already found in Nginx.

We can offer funding for such a feature if feasible assuming this is  
open sourced and preferably ends up in upstream if Igor sees fit.  
Please contact me off list for further discussion if you're interested!

Thanks,
Johan Bergström
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Purge support for (fastcgi|proxy)_cache

Dave Cheney
Hi Johan,

Can you not just delete the cache files on disk ?

Cheers

Dave

On 21/07/2009, at 10:34 PM, Johan Bergström wrote:

> Hey guys (and girls)
>
> We're using fastcgi_cache/proxy_cache quite extensively at our  
> sites, and are in dire need of purging content from our cache.  
> Explicit files will do in our case, but I clearly see the point of  
> wildcards. The only config option I can think of (except modifying  
> parts related to proxy_cache and fastcgi_cache such as  
> proxy_cache_methods) is some kind of "allow_purge" ACL that is  
> similar to the allow-directive already found in Nginx.
>
> We can offer funding for such a feature if feasible assuming this is  
> open sourced and preferably ends up in upstream if Igor sees fit.  
> Please contact me off list for further discussion if you're  
> interested!
>
> Thanks,
> Johan Bergström


Reply | Threaded
Open this post in threaded view
|

Re: HTTP Purge support for (fastcgi|proxy)_cache

Piotr Sikora
In reply to this post by Johan Bergström
Hello,
I'm reaching out in response to your post on nginx's mailing list.

I'm interested in developing purging feature for nginx's cache. Since I run
my own software development company, we are talking about funded development
here.

From what I understand, you'd like to allow IPs from "allow_purge" to
request:
---
PURGE /some/content HTTP/1.1
Host: www.website.com
---
and receive either 200 OK, 403 Forbidden or 404 Not Found.

Is that correct? Does this cover all functionality that you would like to
get?

Would you prefer to see this as "standalone module" or patch / modification
for existing nginx code?

My company is located and registered in Poland, and I believe that yours is
in Sweden, so you can get intra-EU invoice, as long as you can provide valid
EU-VAT number.

Best regards,
Piotr Sikora < [hidden email] >


Reply | Threaded
Open this post in threaded view
|

Re: HTTP Purge support for (fastcgi|proxy)_cache

Johan Bergström
In reply to this post by Dave Cheney
Hello,

On Jul 22, 2009, at 24:15 , Dave Cheney wrote:

> Hi Johan,
>
> Can you not just delete the cache files on disk ?

We tried this but encountered problems, so we're currently populating  
the nginx cache from python in the cases where we need purging instead  
of pulling stuff trough nginx.

>
> Cheers
>
> Dave
>
> On 21/07/2009, at 10:34 PM, Johan Bergström wrote:
>
>> Hey guys (and girls)
>>
>> We're using fastcgi_cache/proxy_cache quite extensively at our  
>> sites, and are in dire need of purging content from our cache.  
>> Explicit files will do in our case, but I clearly see the point of  
>> wildcards. The only config option I can think of (except modifying  
>> parts related to proxy_cache and fastcgi_cache such as  
>> proxy_cache_methods) is some kind of "allow_purge" ACL that is  
>> similar to the allow-directive already found in Nginx.
>>
>> We can offer funding for such a feature if feasible assuming this  
>> is open sourced and preferably ends up in upstream if Igor sees  
>> fit. Please contact me off list for further discussion if you're  
>> interested!
>>
>> Thanks,
>> Johan Bergström
>
>