cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RT] More on caching, expires, and proxy-friendly headers
Date Tue, 11 Feb 2003 13:45:38 GMT
Gianugo Rabellino wrote:

> Stefano Mazzocchi wrote:


>> Question: (and an important one)
>> Suppose you have a resource like
>>  /images/logo
>> that you hit with two different user agent and that a pipeline 
>> renders differently depending on the user agent, how can a proxy 
>> behave friendly to this? do we have a way to specify that a specific 
>> request has to be matched not only against a URI but also against the 
>> user-agent that requested it?
> This can be done in a theory, once (and if) we'll have real proxy 
> support in place. The first thing that can be done is starting to have 
> real "Etag" support: an "Etag" is an unique identifier (think 
> checksum) that represents the given URI from a server side view. This 
> means that the same URI can lead to different etags being generated, 
> according to internal server logic (request parameters, user agents, 
> you name it). รน
> Since an Etag is just a string, I guess that the cache key could do 
> the job, but I'm not sure that it might be the better way security 
> wise (you'll end up handing to the world your private cache keys, I'm 
> not sure that this is a good thing). Also, Etags are useless if there 
> is no conditional request handling: the proxy will ask Cocoon "give me 
> that URI, identified by this Etag, if not modified since this 
> timestamp": Cocoon must be able to analyze that query and reply either 
> with an 304 status code (not modified) or with a 200 with the actual 
> content.
> In this particular case, however, the cleanest solution is using the 
> HTTP/1.1  "Vary:" header. This header is supposed to contain all the 
> request fields that must match for a proxy to decide that a resource 
> is still valid even if requested by different users. Here you can 
> specify that the user-agent is one of such headers, but:
> 0. this is one of the most undocumented headers around;
> 1. you still have to support Etags too (don't really know why);
> 2. there is no advanced feature like regular expressions or substring 
> (proxies might implement it, but it's outside your control), so 
> slightly different user agents (language, version, operating systems) 
> will lead to regeneration;
> 3. I dare you to find a clean solution from the sitemap POV to express 
> this kind of conditions. :-)


ObjectModelHelper.getResponse(objectModel).addHeader("Vary", "User-Agent");


To unsubscribe, e-mail:
For additional commands, email:

View raw message