Dominik, "Shared" does not necessarily mean static in the scope of the whole application - the resource itself may in fact be session specific.
Regards - Cemal http://www.jWeekend.co.uk http://jWeekend.co.uk Dominik Drzewiecki-2 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: >> >> >> >> >> alt="programatically-resourcereference" >> >> >> src="resources/org.drzewo.dummy.web.pages.OtherPage/java_powered_logo.gif;jsessionid=379002689AD867A2CC4A6BDD717FA439"/> >> >> >> 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. >> > > > -- View this message in context: http://www.nabble.com/Wicket%2C-url-rewriting-and-shared-resources-browser-caching-tp20508529p20515360.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
