Ticket #9436 (confirmed Bug)

Opened 7 years ago

Last modified 4 years ago

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.

Change History

comment:1 Changed 7 years ago by ruddo

btw this patch, I am shipping it in my plone packages.

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:3 Changed 7 years ago by kleist

  • Component changed from Unknown to Internationalization

comment:4 Changed 7 years ago by wichert

  • Owner set to hannosch

comment:5 Changed 7 years ago by encolpe

  • Keywords TuneUp added

comment:6 Changed 7 years ago by ruddo

Selected for the TuneUp? Excellent! Thanks guys, yer doing a great job here!

:-)

comment:7 Changed 7 years ago by jluvsu2

  • Keywords TuneUp20 added; TuneUp removed

comment:8 Changed 7 years ago by hannosch

  • Owner hannosch deleted

comment:9 Changed 7 years ago by jluvsu2

  • Keywords TuneUp21 added; TuneUp20 removed

comment:10 Changed 6 years ago by jluvsu2

  • Keywords TuneUp22 added; TuneUp21 removed

comment:11 Changed 6 years ago by aclark

  • Owner set to aclark
  • Status changed from new to assigned

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:13 Changed 6 years ago by jluvsu2

  • Keywords TuneUp22 removed

comment:14 Changed 4 years ago by kleist

  • Status changed from new to confirmed

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]

 http://pypi.python.org/pypi/Products.PloneLanguageTool

Note: See TracTickets for help on using tickets.