2008/11/15 Johan Compagner <[EMAIL PROTECTED]>: > 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 >
Well, therefore the resource, or the component it belongs to should provide a hint whether it is stateless or stateful (depedant on the session). I assume most of the resources such as CSS and images being stateless in terms of not being bound to any particular session. /dd > 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. >>> > >> >
