I noticed this is an existing JIRA issue that was apparently fixed in 1.4 but I'm seeing the double package resources in the cache using an up to date 1.5-SNAPSHOT.
Existing JIRA issue: https://issues.apache.org/jira/browse/WICKET-2999 >I just opened IE and with a new clean session went to our website and >voila - IE sees the .js files with jsessionid as different to the ones >without it and so there are two of every .js file required by both the >home page and the second page I visited. > >I imagine if user visits a site on a regular basis but at intervals >sufficient for the last session to expirre then they will be forced to >download add an extra set of .js files which will get stored in the >browser's cache, even though the .js file has not changed. > >A URL referencing a .js file should *never* need a jsessionid attached >to it. It would be good if we could stop that somehow. They have version >numbers built into their names so the browser will never end up trying >to use a 'stale' .js file. > >Regards >Chris > >________________________________ > >From: Chris Colman [mailto:chr...@stepaheadsoftware.com] >Sent: Wednesday, 11 January 2012 9:37 PM >To: users@wicket.apache.org >Subject: Javascript resources and jsessionid > >I realize that the servlet container is responsible for URL rewriting >and hence adding the jsessionid but I was after an opinion: > >Is it right that Javascript resources get URLs rewritten to include the >jsessionid when search engines access a website? >(And indeed for normal users on their first visit to the site). > >Eg., > ><script type="text/javascript" >src="wicket/resource/org.apache.wicket.extensions.ajax.markup.html.moda l >.ModalWindow/res/modal-ver-1326193494000.js;jsessionid=3E45F45F056AF2BC F >CFD030B489F832A"></script> > > >I guess for search engines it doesn't matter as they won't be >downloading the .js anyway - the jsessionid just adds extra clutter to >the HTML - but for normal users with cookies enabled it could cause the >.js downloaded after a new session is created to be redownloaded when >the next page is requested because at that stage the server would have >established that the client supports cookies and so would not render >subsequent pages with jsessionidS suffixed to the .js references. > >Depending on how smart the browser's cache is it might see the jsession >suffixed .js and the clean .js as two separate resources and do a second >download of the .js. > >Hmmm, interesting. > >Again, this is not strictly a Wicket issue but I'd be interested to know >what others think about this. > > >Yours sincerely, > >Chris Colman > >Pagebloom Team Leader, >Step Ahead Software > > >pagebloom - your business & your website growing together > >Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 >Email: chr...@stepahead.com.au <mailto://chr...@stepahead.com.au> >Website: >http://www.pagebloom.com <blocked::http://www.pagebloom.com/> >http://develop.stepaheadsoftware.com ><blocked::http://develop.stepaheadsoftware.com/> > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org