> Ard, > > You didn't really answer his question, but I didn't really > grasp it either.
I thought he meant changing locale in his browser still returning the (cached) pages of the other locale....but obviously, I did not understand correctly :-) Ard > > When Tomcat or Jetty create a session they are going to > create a token > that represents the session will end up in the user's browser > or as part > of each subsequent request. By design, it is not possible for > multiple > end users to share this session, although I suppose it could > be done if > your proxy "owned" the session. However, I've never heard of a proxy > that would do that. > > Can you explain why you would want multiple user's to share a single > session? In fact, why wouldn't you want each user to have > their own locale? > > Ralph > > Ard Schrijvers wrote: > > Hello, > > > > we run all our sites with httpd in front of cocoon (Jetty > or Tomcat), but we are kind of used to not rely on the locale > of the browser, because you cannot be sure all proxies > between the client and your application honour the locale > correctly (you might have proxies in between, for example a > proxy within a company, that caches pages but does not use > the locale..then the first locale gets the page, and > everybody else with different locale's see the same page. We > therefor user /nl, /en, /fr etc as a prefix in the url) > > > > For the rest, I did not totally grasp the picture you > described here, with "changing the locale only the session > ....etc". So, either you use the locale in the url, or try to > explain the timeline of events a little better, because i did > not get it. You did configure httpd (if you use mod_cache) > correctly to honour the locale? > > > > Regards Ard > > > > > > > >> I have a multilingual website implemented with Cocoon 2.1.9 which > >> runs on top of Tomcat 5.5. I use > >> org.apache.cocoon.acting.LocaleAction to keep track of the > current > >> language and have set this up as follows: > >> > >> <map:action logger="sitemap.action.locale" name="locale" > >> src="org.apache.cocoon.acting.LocaleAction"> > >> <locale-attribute>locale</locale-attribute> > >> <create-session>true</create-session> > >> <store-in-request>false</store-in-request> > >> <store-in-session>true</store-in-session> > >> <store-in-cookie>false</store-in-cookie> > >> <use-locale>true</use-locale> > >> <default-locale language="en"/> > >> </map:action> > >> > >> In other words, I store the current locale in the session. > >> > >> This works fine when I call up the website directly from > >> Tomcat (port > >> 8084 in my case). However, I want to use Apache HTTPD 2.0 as a > >> reverse proxy. I have tried using mod_jk and mod_proxy (as > >> per http:// > >> wiki.apache.org/cocoon/ApacheModProxy), but more than one > session is > >> being passed from HTTPD to Tomcat/Cocoon: when I change language, > >> only the session in which I changed the language gets changed > >> and the > >> other remains as it was. > >> > >> I realise this is slightly off-topic for this list, but I thought > >> other Cocoon users might have experienced the same thing > and be able > >> to give me a hint as to how to force HTTPD and Tomcat to use > >> just one > >> session. I've spent all day googling, but all I find is > stuff about > >> load-balancing and sticky sessions when HTTPD is being used with > >> multiple workers. I just have one worker. > >> > >> Steve > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
