Afaik we don't have any control over the urls when url rewriting is in effect. this is the responsibility of the servlet container. Can't do anything about that.
Martijn On Fri, Nov 14, 2008 at 10:20 PM, Dominik Drzewiecki <[EMAIL PROTECTED]> wrote: > I have recently started optimizing our wicket based application in terms of > reducing the number of requests sent by the browser. This can be easily > achieved by assuring the resources (js, css, gif, png and so on) get proper > headers and get cached by the browser so that only a mere HTTP 304 response > gets sent by the server or, even better, no request from the browser is > sent at all. > > I noticed that when the session tracking is based on url > rewriting, resources attached programmatically (as opposed to the resources > "inlined" in the html templates) which urls are rendered by > the o.a.w.markup.html.internal.HeaderResponse render(ResourceReference) > and further by a.o.w.RequestCycle encodeUrlFor(IRequestTarget), get > their respective session id appended to the returned url. > > Adding a simple AjaxFallbackLink to the page results in the > following contibutions to the head section of the rendered page: > > <script type="text/javascript" > src="resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js;jsessionid=379002689AD867A2CC4A6BDD717FA439"></script> > <script type="text/javascript" > src="resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js;jsessionid=379002689AD867A2CC4A6BDD717FA439"></script> > > The same applies to the images inserted using autolinking or manually > as ResourceReference: > > <img > alt="programatically-resourcereference" > src="resources/org.drzewo.dummy.web.pages.OtherPage/java_powered_logo.gif;jsessionid=379002689AD867A2CC4A6BDD717FA439"/> > <img > alt="autolinking" > src="resources/org.drzewo.dummy.web.pages.OtherPage/java_compatible_logo.gif;jsessionid=379002689AD867A2CC4A6BDD717FA439"/> > > The result, in terms of client-side caching, is that the resources > are cached only within the scope of the current session (a they are keyed > in > the client-cache by the url containing sessionid). All of those > resources are easily referrable outside of the session and accessing them > without the > jsessionid suffix results in an appropriate resource returned as well > no additional session allocated on the server (based on jconsole & > wicket-jmx > observations). > > My suggestion is that the resource links should be generated > without jsessionid (although I realize that when the cookie based session > tracking > is enabled they are referred to within the scope of the session as > the request sent for such a resource contais a cookie with a session > id...). > Maybe all of the shared resources should be treated uniformly - as if > they were accessed without a session. > > Cheers, > Dominik Drzewiecki > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
