cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Stevens" <>
Subject Re: [FIX] I18nTransformer [CACHING PIPELINE]
Date Mon, 25 Sep 2006 18:56:54 GMT
>From: "Ard Schrijvers" <>
>Date: Tue, 12 Sep 2006 10:24:53 +0200
> > On 9/12/06, Yves Zoundi <> wrote:
> >
> > > ...If you have any ideas please let me know...
>I just think it works for you: you do think it doesn't because you cannot 
>switch between language in your browser due to browser cache, right? In 
>real live, that doesn't matter, because somebody in fr will get it al the 
>time in fr, and somebody in en all the time in en....
> >
> > Specifiying the locale in the URL path would certainly work
> > around this problem.
> >
> > Even though URL purists (understandably) hate them, URLs like
> >
> >   fr/yourpage
> >   en/yourpage
> >
> > seem like the safest option with today's browsers.
>It is not only about browsers when you have high traffic live sites. with 
>caching on several levels: If you use squid or mod_cache, you might 
>configure caching according the language settings (though
>I don't know how), but normally, when you cache in mod_cache or squid, you 
>cache based on the
>url (inl request params ofcourse). This implies, that the first browser 
>with a hit fills the cache according to that language, serving the same 
>pages to other browsers. If you come with a solution that you *can* specify 
>mod_cache to cache according language settings, I will reply that you then 
>still have the problem that *many* persons these days are within companies 
>having there own proxy, you certainly don't control :-)

The Vary response header would help with this.  See
"A server SHOULD use the Vary header field to inform a cache of what 
request-header fields were used to select among multiple representations of 
a cacheable response subject to server-driven negotiation. ... When the 
cache receives a subsequent request whose Request-URI specifies one or more 
cache entries including a Vary header field, the cache MUST NOT use such a 
cache entry to construct a response to the new request unless all of the 
selecting request-headers present in the new request match the corresponding 
stored request-headers in the original request."

So specifying
response.setHeader("Vary", "Accept-Language");
means that when the French-speaking user requests the page from a proxy 
that's previously cached the English version, it will fetch a fresh copy.  
It's not perfect - if you allow the user to switch languages with a request 
parameter and/or cookie value instead of by selecting an alternate language 
in their browser settings that will suffer the same problem - but it's an 

Similarly, if you're using Cocoon's BrowserSelector to e.g. work around 
browser differences and return different pages/CSS depending on whether the 
user has Firefox or IE, you should include User-Agent in the Vary response 


>So those evangalists hating /fr/foo, well....whatever :-)
>Regards Ard
> >
> > -Bertrand

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

View raw message