Please stop mixing stateless and static. Thank you. Jörn
On Sat, Nov 15, 2008 at 7:34 PM, Dominik Drzewiecki <[EMAIL PROTECTED]> wrote: > 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. >>>> > >>> >> >
