unless we dont rewrite resource urls. in which case we will be in violation of the spec...
-igor On Fri, Nov 14, 2008 at 3:59 PM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > 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. >
