Red Hat Bugzilla – Bug 190185
browser caching is causing issues with locale preference changes
Last modified: 2007-10-23 22:27:16 EDT
Description of problem:
Here's an IRC chat I had with Kevin:
<beth-hm> ksmith: I have browser preference set to korean, and so the RHN pages
are happily displayed in korean when I'm not logged in ...
<beth-hm> ksmith: then I log in and change RHN locale to german. But only some
of the content is displayed in german from that point forward, the rest is still
in korean. The only way to get all german is to close/reopen the browser. That
doesn't seem right to me.
<ksmith> beth-hm: that is browser caching in action. that'll require some
investigation to figure out the best way around that.
<ksmith> beth-hm: open a bug and assign it to me
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. See chat session above.
And even closing/reopening the browser doesn't completely fix it.
Sadly, browser caching does not completely explain the reported behavior. I
enabled Struts' no-caching support via the following XML snippet in
And verified that the appropriate headers were being sent to the browser. This
cleared up a few minor instances of wrongly cached content. This didn't fix the
bulk of the problem.
After more digging I've unearthed a multi-layer problem which will take a bit to
fix correctly. Here are the issues I know about:
1) We are using the <%@ include %> directive to include our html fragment files.
This directive is meant for static content and has caching and other
persistence-related problems when used with dynamic content
<jsp:include> tag should be used since it is more compatible with dynamic content.
2) Fragment files end in .jspf.
By default the jsp servlet is mapped to *.jsp and *.jspx. Once I addressed #1
and converted the user locale preferences page to use <jsp:include> I had
problems getting the include fragment to execute, ie I was seeing raw,
unexecuted jsp tags in the browser (<c:out>, <c:if>, etc). I was able to fix
that by adding the following servlet mappings to web.xml:
3) Fragment files do not contain necessary taglib declarations
In fixing #2 I discovered that some custom tags were not executing. Further
digging revealed that most of our jsp fragments do not include necessary taglib
declarations, instead relying on the including page to declare the necessary tags.
After addressing all the above issues for the user locale preferences page I am
still not seeing localized text change uniformly when the user's locale changes.
My current suspicion is that something in our templating mechanism is getting in
the way. My investigation continues.
Discovered the actual cause of the problem this morning. Struts' MessageResource
class caches, IMHO very very incorrectly, the first value resolved for a given
localized string. Subsequent calls return the cached value instead of performing
the lookup again. This ultimately has the effect of resolving only one
translation per localized string -- meaning that a string can be resolved to
only one language, period.
I was able to workaround this behavior by clearing MessageResource's cache in
each call to getMessage(). I've verified that this fix works without the fixes
noted in my previous update. I still feel that the above items are things which
should be addressed, but since they are not required to fix the actual problem
reported I will leave them out of the committed fix.
1) Login to RHN
2) Click the Locale Preferences selection
3) Select a locale and save
Expected Result: The entire locale preferences page should render in the new
Verified. I moved locales all over the place, changed the browser locale, etc.
closing -- currentrelease