cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Winnall <st...@winnall.ch>
Subject Re: [Slightly OT] Session problem with Apache-fronted Cocoon site
Date Mon, 09 Jul 2007 09:24:09 GMT
Ard, Ralph

Thanks for your questions, which have forced me to think harder about  
my problem. I have found a solution by reading the following thread,  
which may be useful for other people:

	http://marc.info/?l=apache-httpd-users&m=116956392724131&w=2

For the record, I'll try to explain more carefully what the problem was.

I use the session cookie (JSESSIONID) to store information about the  
current browser session (locale, but also browser, OS...). From the  
point of view of a Cocoon sitemap, this is "storing data in the  
session" as opposed to creating an explicit cookie or using a query  
string.

When I used the browser to talk directly to Tomcat on port 8084,  
JSESSIONID was passed back and forth correctly and the session data  
was available everywhere. However, when I used Apache HTTPD as a  
reverse proxy in front of Tomcat, JSESSIONID seemed to be getting  
lost for some requests from the browser, so Tomcat created a second  
session. This meant that session data was not available everywhere.  
The cause for the problem was between my ears: I was using two  
different hostnames (localhost and a FQDN), so the browser actually  
had two JSESSIONIDs, one for each hostname. For some reason, the  
different hostnames did not cause a problem between the browser and  
Tomcat, but did cause a problem between the browser and Apache HTTPD.  
If I use the same hostname everywhere, there is just one JSESSIONID.

I hope the explanation above is clear enough. Thanks for helping me  
to think about it!

Steve
	
On 9 Jul 2007, at 10:31, Ard Schrijvers wrote:

>
>> 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: users-unsubscribe@cocoon.apache.org
>>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message