Ticket #9436 (confirmed Bug)
plonelanguagetool wrecks caching
Reported by: | ruddo | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | Future |
Component: | Internationalization | Version: | 4.1 |
Keywords: | Cc: |
Description
Every time a request comes in from a user's browser which does not have an I18N_LANGUAGE cookie set, plonelanguagetool sets it. This is a huge problem because now the cookie is set and the page can no longer be cached by caching proxies in front of plone. And not just the page itself, but every element in the page too, because the browser sends the cookie with every subsequent request.
This problem only takes place if the language tool in the ZMI has been set up to use cookie for manual override of course.
Attached is a patch to fix it. Now the cookie is only set when a ?setLanguage=XXX URI is accessed. This way, users who do not want to manually override the language using the flags, but are happy reading the pages as they go, do not have their browsing performance destroyed, proxying caches can effectively offload requests from plone, and cachefu can do its job.
As an aside, in case anyone is interested, I have concocted a nice varnish recipe that will strip the language cookie and change the accept-language in the header to the language of the cookie itself. the idea is that the cookie never actually hits plone and plone does language negotiation based on the "browser preferences" instead. This recipe, naturally, fixes a problem in plone with etags too. My recipe also eliminates the duplicate page in Google problems arising ?from using the set_language=XXX query string parameter without redirecting the user to the appropriate end URI.
Attachments
Change History
Changed 7 years ago by ruddo
comment:2 Changed 7 years ago by ruddo
tldr: plone language tool sets cookie in every single request, whether the user has chosen to override the language or not. this wrecks proxy caching for casual visitors or search engine traffic.
comment:6 Changed 7 years ago by ruddo
Selected for the TuneUp? Excellent! Thanks guys, yer doing a great job here!
:-)
comment:12 Changed 6 years ago by aclark
- Status changed from assigned to new
- Owner aclark deleted
- Milestone changed from 3.x to Future
Another one for future:
09:10 < aclark> hannosch: any thoughts on http://dev.plone.org/plone/ticket/9436 ? 09:10 -!- fschulze is now known as mr 09:10 -!- mr is now known as mr_developer 09:11 < aclark> mr_developer: :-) 09:11 <@hannosch> aclark: that's on my LinguaPlone todo list as well 09:11 <@hannosch> it's not as simple as the bug suggests though 09:13 < aclark> hannosch: how so? 09:14 -!- pelle_ [n=pelle@0x5da26d82.cpe.ge-1-1-0-1101.bynqu1.customer.tele.dk] has quit ["zzzzzzzzzzzzzzzz"] 09:14 <@hannosch> aclark: it all very much depends on the language policy you have in a site and how negotiation should work 09:14 <@hannosch> the current behavior always works, not doing it only works under certain restrictions 09:15 <@hannosch> I'm working on LinguaPlone itself quite a bit these days. once we have a sane new default language setup, we can also change the default negotiation policy 09:16 <@hannosch> right now you cannot do anything about that bug report. leave it or put it to "future"
comment:15 Changed 4 years ago by mikerhodes
- Version set to 4.1
Looks like this may have been fixed or at least affected in 3.1.0 with a new(?) setting:
3.1.0 - 2011-05-12
Make set_cookie_everywhere default to False on new sites. Most sites have only a single language and setting cookies for anonymous users hurts cacheing. [elro]