Re: sessionid-encoded URLs patch

Alex,

My 2 cents on this.

As I see oscache has 2 ways of coming up with unique keys for content to be put in the cache.
1. URL based keys.
2. Developer supplied keys.

The cache is scoped based, application or session scoped, the default being application scope.

When using APPLICATION scope:

URL based keys in application scope, (i.e. cached content that applies to the entire application),
I think it makes sense, to not include the jsessionid variable found in the URL when oscache
generates the entry key for the content to be cached. Leave the jsession in the URL so the servlet
can tie it back to a session, but in the oscache world the key generated will be generic and not
for a specific established session.  This would allow other sessions to get to this application
wide cached content.

This logic would also work for the oscache-filter for mapped URLs that are application-scoped as
well.

When using SESSION scope:

Here I am not sure?  I have not really paid any attention how oscache is keeping cached content
for a specific session, so I can’t help here.

My blind guess, currently oscache handles caching session-scoped content successfully when the URL
does NOT have the jsessionid in it.

If jsessionid is found in the URL, again removing it when generating the key may do the trick.

Wally


--- Alex Burgel <[email protected]> wrote:
> hi,
> 
> i put a patch in jira
> (http://jira.opensymphony.com/secure/ViewIssue.jspa?id=22549)
> 
> it attempts to solve the problem of caching pages with session ids encoded
> in URLs.
> 
> the patch is just a first attempt, so there are some issues... notably, it
> doesn't fix anything with the cache filter, in fact it might have broken it.
> but aside from that it, it works well.
> 
> it works by taking pages that could possibly have a session id in them, and
> running them through a filter which replaces the id with a token... then
> when the page is removed from the cache it replaces the token with the
> current id.
> 
> the downside is that it requires 2 versions of each page, 1 with the session
> token, and 1 without.
> 
> it requires a new property in the oscache.properties file
> 'cache.use.session.flag.in.key' which is false by default. set it to true to
> get this all to work...
> 
> 
> please take a look at the patch and send me any comments.
> 
> thanks.
> 
> --alex
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Opensymphony-oscache mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-oscache


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/