igor.vaynberg wrote:
> 
> http://techblog.molindo.at/2008/08/wicket-interface-speed-up-caching-resources-forever.html
> 
> -igor
> 
> 

I'm not quite sure if it wraps the case of generating sessionless url's to
static resources when url rewriting 
is used to keep track of the session instead of cookies. 

My original intent for the first post in this thread was to point out the
fact that the resources such as css or javascript libraries (that never ever
differ in content regardless of the session such as wicket-event.js) indeed
do get cached by the browsers, but due to the fact that it is the url that
is the key for the cache, another request from the same browser but within
another session results in a "miss" in a cache and the resource gets
retrieved from the server again and put in the cache (for not being used
ever again outside of the current session). Just consider getting all java
scripts again and again on each subsequent logging in to your gmail. With
session tracking based on cookies this never happens. 

My original idea to solve this was to use the
HttpServletResponse.encodeUrl() conditionally for generating urls to the
resources put in the output markup. Generated urls that are session scoped
should be passed via this method, but the ones that definitely aren't should
be inlined as-is (thus omiting the call). 
Igor was wondering if such a behaviour would be against the servlet specs. I
assure you that it is completely up to you whether you use encodeUrl() or
not when generating urls, as long as you know what you are doing (i.e.
whether this jsessionid suffix is useful or not). Otherwise it would have
been put as a core functionality of the container to rewrite all urls
whenever url rewriting based session tracking was in effect, rather than be
exposed as an API. 

Bottomline: Do not append jsessionid (omit the encodeUrl() call) whenever
you know that when such a resource is requested you just ignore the
jsessionid.

regz,
/dd


-- 
View this message in context: 
http://www.nabble.com/Wicket%2C-url-rewriting-and-shared-resources-browser-caching-tp20508529p23094714.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Reply via email to