I do not see any violation of the specs in embedding the links to the shared resources without a jsessionid (likewise one would do when inserting those resources into html templates). I didn't look at the specs thoroughly thou, but the javadocs on the encodeURL(String) says: <snip>For robust session tracking, all URLs emitted by a servlet should be run through this method. Otherwise, URL rewriting cannot be used browsers which do not support cookies.</snip> The key clause is "for robust session tracking". The question is, whether wicket indeed does something about those session ids (whether obtained from the cookie or url) when processing requests for the resources or simply disregards them (I think I've seen some jsessionid stripping somewhere in the wicket sources, AFAIR in some parts of the code responsible for server-side caching of resolved resources). The simple solution is: When generating urls we should use HttpServletResponse.encodeURL(String) conditionally based on the evaluation whether the resource the url is referring to is a shared resource or not.
regz, /dd 2008/11/15 Igor Vaynberg <[EMAIL PROTECTED]> > > unless we dont rewrite resource urls. in which case we will be in > violation of the spec... I wouldn't call this a violation. > > -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. > >
