But we alread have 'stateless' hints, couldn't we do anything with this
mark sharedresources stateless? Or have a specific stateless resources?
On 11/15/08 2:16 PM, jWeekend wrote:
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.
