Enterprise Client Community

We are using BufferedContentServlet and ...Mgr to store files to be displayed in browser which is opened by the captaincasa client via jshowurl.

The url that is passed contains the session id via url rewriting (somefile.ccbuffer;jsessionid=xyz).

If there is already an open browser which has accessed stuff on our server, whereby a session id has been set via cookie, the new window will inherit this cookie and send both the (incorrect) cookie session id and the (correct) session id in the url. It seems that tomcat extracts both ids, but the cookie will win, so the request for the buffered content will be handled in the wrong session, and nothing is retrieved.

Hi,
yes, we understand the problem. Do you need the browser cookie for a certain reason? If not: with Tomcat you can define not to use cookies at all (META-INF/context.xml).
If you require the cookie for some reason... - hmmmm - then we have to continue to think about it.
Regards, Björn

We have been using session in various places, given that our server must be able to handle both casabac and captaincasa scenario. It would be a formidable task to go through all our application end ensure that every url passed to the client is enhanced via url-rewriting, so I am afraid that disabling session cookies is not a short term option.

In my concrete testcase the session is created via a /favicon.ico request which returns 404-not found and in creating the error response tomcat creates a session, setting a cookie to path "/".

regards
Manfred

Hi,
I do not want you to switch off all cookies! I only think about the concrete webapp in which you run CaptainCasa - but this seems to be the same as the one you run e.g. Casabac in.
Björn

After several communication about this by mail, here some interim summary.

The problem is not generically solve-able by a programmatic approach: if the CaptainCasa client starts the browser, and the browser is already associated by cookie with a certain session id then this session id is taken to the server as cookie.

On server side the cookie-sessionid is stronger that the rewritten sessionid, so there is some confusion about the session assignment.

This means - in this scenario, someone "in fron of Tomcat" (e.g. Apache server, ...) needs to wipe out cookie data from certain request. To simplify the corresponding configuration we from today's version on, always start URLs from the buffered-content-management with "/ccbuffer/" so that you can easily identify.

...this is an interim result, currently. Of course some nicer ideas are welcome from any side!

Björn