RE: Javascript resources and jsessionid - existing JIRA issue fixed in 1.4

[Chris Colman <ch...@stepaheadsoftware.com>]

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:chrisc@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: chrisc@stepahead.com.au <ma...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org