ATS supports HTTP PURGE method to remove the contents from the cache based on 
the request URL. 

Another more efficient approach is to simply alter the cache key for the 
associated resource to something that's different from the current.

There's no direct out of the box (via config or a built in plugin) that can 
purge based on a request header, AFAIK. However, using the available TS API, it 
should be simple enough to write a custom plugin that can do it. 

Below are some relevant example plugins that invalidate cache entries 
efficiently by altering the associated cache keys.

https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/remap_purge.en.html

https://github.com/apache/trafficserver/blob/master/plugins/experimental/remap_purge/remap_purge.c

https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/regex_revalidate.en.html

https://github.com/apache/trafficserver/blob/master/plugins/regex_revalidate/regex_revalidate.c

- Sudheer

> On Nov 23, 2016, at 2:25 AM, Pachler, Uwe <[email protected]> wrote:
> 
> Hello,
> 
> I'm considering to use a HTTP Cache in front of a web application I'm 
> developing. I'd operate the cache as a transparent proxy to cache dynamic 
> resources that are only accessible via authentication (with Vary: 
> Authorization header set, so each user's version is cached separately). What 
> a user can and can't see depends on permissions configured for that user in 
> the web application, and permissions can change over time. Authentication is 
> handled only by the web application.
> 
> From what I've read Apache TS would fit this scenario perfectly, but there is 
> an open question I could not find an answer for: If a user's permission to 
> see a resource is revoked in the web application, that resource is still 
> cached until it becomes stale, so it is still visible. So that change in 
> permissions is not in effect as long as the resource is still considered 
> fresh by the cache.
> However, because the web application knows when a users permissions change, 
> it could simply tell the cache to invalidate (evict) all resources in the 
> cache that match the user's authorization header. 
> 
> So is there a way to programmatically (e.g. HTTP service call, etc.) evict 
> all resources matching an Authorization header?
> 
> Kind regards,
> 
> Uwe
> 

Reply via email to