| | PURGE http://cachehost/someuri HTTP/1.1
| |
|
| Isn't it better to do it as a uri - say - /cache-control - hosted on the
| proxy?
| so the above would look like
|
| POST /cache-control?purge
|
| http://cachehost/someuri1
| http://cachehost/someuri2
| http://cachehost/someuri3
|
|
|
For one reason or another, I need to be able to invalidate cache
entries in some mod_cache caches. There's no good standard for this,
WCIP/BEEP went nowhere afaict, but I want to keep things simple. The
way Squid handles this is by implementing a non-standard PURGE HTTP
method, so I've taken the
On Fri, 30 May 2008, Colm MacC?rthaigh wrote:
For one reason or another, I need to be able to invalidate cache
entries in some mod_cache caches. There's no good standard for this,
Aye - common problem!.
PURGE /foo HTTP/1.1
..
While above is 'always' a good/sensible approach. I'd like:
On Fri, May 30, 2008 at 10:35 AM, Dirk-Willem van Gulik
[EMAIL PROTECTED] wrote:
something more like mod_proxy_balancer's full-scale html interface for
doing this kind of thing at run-time?
No, totally nut - bot I am much more interested in a deeper, programmatic,
interface - which I can hook
On 05/30/2008 11:13 AM, Ruediger Pluem wrote:
On 05/30/2008 10:28 AM, Colm MacCárthaigh wrote:
For one reason or another, I need to be able to invalidate cache
entries in some mod_cache caches. There's no good standard for this,
WCIP/BEEP went nowhere afaict, but I want to keep things
[..]
| The patch actually works, you can call;
|
| PURGE /foo HTTP/1.1
| Host: example.org
| Accept: foo/bar
|
[..]
| the PURGE request. So sending a PURGE request to 127.0.0.1:8080 with the
| caching
| virtual host being 'cachehost' will look like:
|
| PURGE http://cachehost/someuri HTTP/1.1
On fre, 2008-05-30 at 11:06 +0200, Colm MacCárthaigh wrote:
Yep, Squid will delete all variations of an entity when you use
Accept: */*, that isn't easy with our current approach, but I'll see
what I can do - it would be nice.
Squid isn't quite that good on purging variants either..
Regards
On Fri, 30 May 2008, Ruediger Pluem wrote:
It would be also nice if the purge could be enabled only in a virtual host
different
..
PURGE http://cachehost/someuri HTTP/1.1
Would a normal Limit PURGE etc sort of thing on the Location not do this
? Or is location too path centric ?
Dw
On 05/30/2008 12:43 PM, Dirk-Willem van Gulik wrote:
On Fri, 30 May 2008, Ruediger Pluem wrote:
It would be also nice if the purge could be enabled only in a virtual
host different
..
PURGE http://cachehost/someuri HTTP/1.1
Would a normal Limit PURGE etc sort of thing on the Location
On 05/30/2008 11:39 AM, rahul wrote:
[..]
| The patch actually works, you can call;
|
| PURGE /foo HTTP/1.1
| Host: example.org
| Accept: foo/bar
|
[..]
| the PURGE request. So sending a PURGE request to 127.0.0.1:8080 with the
| caching
| virtual host being 'cachehost' will look like:
|
How we handle purge:
-Our cache is only disk based, so it is somewhat easier.
-We have a hook that gets called after each cache store - ie, after we write
a vary meta file, after we write a real meta file, after a datafile write
(on close).
-We also have a cache_get_info function that is exported
On Fri, May 30, 2008 at 1:59 PM, Akins, Brian [EMAIL PROTECTED] wrote:
How we handle purge:
Oh that reminds me, a long time ago, I wrote htcacheadmin - a generic
command line utility for administering mod_disk_cache caches. Which is
how I /used/ to handle this situation. (I've attached the
On 05/30/2008 05:14 PM, Colm MacCárthaigh wrote:
On Fri, May 30, 2008 at 1:59 PM, Akins, Brian [EMAIL PROTECTED] wrote:
How we handle purge:
Oh that reminds me, a long time ago, I wrote htcacheadmin - a generic
command line utility for administering mod_disk_cache caches. Which is
how I
13 matches
Mail list logo