Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E48FE82.80108@verizon.net>
Date: Tue, 11 Feb 2003 08:45:38 -0500
From: Vadim Gritsenko <vadim.gritsenko@verizon.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] More on caching, expires, and proxy-friendly headers
References: <3E48D71B.7080004@apache.org> <3E48F2A0.8070006@apache.org>
 <3E48FB26.9020405@apache.org>
In-Reply-To: <3E48FB26.9020405@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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