Wicket doesnt do anything with the sessionid that is for the servlet container, the problem is that shared resources can still use the session for generating the real resource, so we could not encode it but then the resource has to tell us that through some state, so that we know it is a complete stateless resource
On 11/15/08, Dominik Drzewiecki <[EMAIL PROTECTED]> wrote: > 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. >> > >
