[
https://issues.apache.org/jira/browse/WICKET-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272282#comment-13272282
]
Michael Bruns commented on WICKET-4550:
---------------------------------------
As (bad) luck would have it we just tripped over another error caused by this
bug :-(
Our Tomcats are clustered, i.e. there are three of them behind a load balancer.
The sessions are sticky, so that a user stays on the same Tomcat throughout his
session. Now we ran into this constellation:
* A new version of our application has been freshly deployed to the three
Tomcats T1, T2 and T3.
* A page mounted at /somePage (or a component used in this page) mounts an
image to static URL /img/something.png on instantiation, i.e. when the page is
accessed for the first time.
* A user logs into a new session on Tomcat T1 and accesses the page /somePage.
* The resource link to /img/something.png served by T1 on page /somePage
doesn't contain a jsessionid.
This will lead to the fact that the new session for /img/something.png, be it
temporary or not, will be created on either of the three Tomcats. However,
/somePage has only been accessed on T1, which means that both T2 and T3 have
not yet mounted the image on the given path and will thus answer with a 404.
Only when /somePage has been accessed on all three Tomcats the image will
always be delivered. Before that, there is always a chance of 2/3 or 1/3 that
you'll get a 404.
> jsessionid is not added to resources if cookies are disabled by the server
> --------------------------------------------------------------------------
>
> Key: WICKET-4550
> URL: https://issues.apache.org/jira/browse/WICKET-4550
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.5
> Reporter: Michael Bruns
> Attachments: jsessionid-quickstart.tar.gz
>
>
> When I configure the container (either Jetty or Tomcat) to not support
> cookies, I expect the jsessionid to be added to all resource links in the
> page. However, with Wicket 1.5.5 this isn't the case, i.e. all URLs are
> lacking the jsessionid, both in development and deployment mode.
> Example IS:
> <script type="text/javascript"
> src="wicket/resource/org.apache.wicket.markup.html.WicketEventReference/wicket-event-ver-1331911540000.js"></script>
> Example SHOULD:
> <script type="text/javascript"
> src="wicket/resource/org.apache.wicket.markup.html.WicketEventReference/wicket-event-ver-1331911540000.js;jsessionid=${something}"></script>
> This creates a new session for each and every resource in the page, which is
> an undesirable behavior. I have found a few issues regarding this topic, e.g.
> WICKET-4334 and WICKET-4312, but none of them could give me a clue about why
> it doesn't work the way I expect it. In Wicket 1.4.x the jsessionid was added
> to all resource links, so everything worked fine and the current session was
> reused.
> I created a quickstart do demonstrate the behavior - please see the attached
> file. The file jetty-web.xml tells Jetty to not support cookies, so mvn
> jetty:run can be run without any further configuration.
> By the way, I found a suggestion to use a custom IResourceCachingStrategy to
> append the jsessionid (or whatever) to URLs of resources in the archive of
> the mailinglist. Unfortunately, this doesn't work because the URL is encoded
> afterwards and the ; is turned into %3B.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
