cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
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. :-)



Ahem...
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoon/selection/BrowserSelector.java?rev=1.7&content-type=text/vnd.viewcvs-markup

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


Vadim



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message