trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Tolley <>
Subject Re: Plugin problems
Date Wed, 23 Feb 2011 00:12:47 GMT
On Tue, Feb 22, 2011 at 04:11:54PM -0700, Leif Hedstrom wrote:
> sorry for the late reply, hopefully you're still looking for an answer  
> to get going with Apache TS :).

To be honest, those leading the project in question have pretty much decided
to go with another option, however I'm still interested in knowing what's
going wrong, in particular for possible use of TS with other projects.

>> For instance, I set up traffic server as a reverse proxy, in front of a local
>> apache instance. I tried using cache.config to cache all png files and no html
>> files, like this:
>> url_regex=localhost suffix=png ttl-in-cache=10m
>> url_regex=localhost suffix=html action=never-cache
> I suspect this is a bug, it seems we do not honor / use the suffix "mod"  
> properly. I've filed a bug (TS-674) to track this.

I'm glad it's not obviously my fault :)

> Hmm, the "example" headers generally are intended as "examples" only,  
> i.e. not for production use. As such, they ought to still use, but no  
> one really is testing them afaik. I've made a slightly better example  
> plugin for headers manipulation available on the SVN server, in
> Note that this plugin requires current trunk to compile as of a few days  
> ago.

I'll have to check it out. I realized the example plugins didn't really do
anything a production system might actually want, but I wasn't able to get
them to do anything, really.

>> Finally, a more general question. The documentation says plugins can't modify
>> the cache directly. Some of our requirements are that we need to cache or not
>> cache objects based on headers, cookies, etc., but I'm not entirely sure
>> that's actually possible. I'd appreciate any comments you can give. Thanks in
>> advance.
> You can't (easily) modify HTTP objects once they are in cache. But you  
> can modify objects before they get in cache, or modify the responses so  
> that they don't end up in cache etc. I hope that makes any sense?

That does, and is kinda what I was thinking we'd have to do. For instance,
some of our business logic said, "Given the presence of various
application-specific headers or cookies, use the cache where normally we
wouldn't, or alternatively, don't use it where we typically would." I assume
the technique in this case would be to modify headers at some point in the
process such that TS would decide to cache the response on its own?

- Josh

View raw message