You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Dominik Drzewiecki <do...@gmail.com> on 2008/11/14 22:20:47 UTC
Wicket, url rewriting and shared resources browser caching
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
Re: Wicket, url rewriting and shared resources browser caching
Posted by Jörn Zaefferer <jo...@googlemail.com>.
Stateless doesn't equal static. A stateless resource can still serve
completely different content based on the session id. Afaik stateless
just means that the state of the component isn't stored in the
session, but instead in some database (usually application state) or
is delivered as part of the request, usually get paramters.
Jörn
On Sat, Nov 15, 2008 at 3:43 PM, Thijs Vonk <vo...@gmail.com> wrote:
> 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<ig...@gmail.com>
>>>
>>>>
>>>> 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
>>>> <ma...@gmail.com> 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
>>>>> <do...@gmail.com> 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.
>>>>>
>>>>>
>>>
>>>
>>
>>
>
>
Re: Wicket, url rewriting and shared resources browser caching
Posted by Thijs Vonk <vo...@gmail.com>.
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<ig...@gmail.com>
>>
>>> 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
>>> <ma...@gmail.com> 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
>>>> <do...@gmail.com> 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.
>>>>
>>>>
>>
>
>
Re: Wicket, url rewriting and shared resources browser caching
Posted by jWeekend <jw...@cabouge.com>.
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 <ig...@gmail.com>
>>
>> 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
>> <ma...@gmail.com> 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
>> > <do...@gmail.com> 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.
Re: Wicket, url rewriting and shared resources browser caching
Posted by the_adam <ad...@gmail.com>.
On as side note, I'd still say that stateless means no session id.
Jörn Zaefferer-2 wrote:
>
> Stateless doesn't equal static. A stateless resource can still serve
> completely different content based on the session id.
>
If a returned resource is looked up anywhere BASED on the information within
the session (including session id itself) it wouldn't be stateless. Truly,
stateless can be non-static, but then the dynamic part would come from i.e.
request parameters (or be randomly generated, whatever).
--
View this message in context: http://www.nabble.com/Wicket%2C-url-rewriting-and-shared-resources-browser-caching-tp20508529p23095812.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Wicket, url rewriting and shared resources browser caching
Posted by Dominik Drzewiecki-2 <do...@gmail.com>.
igor.vaynberg wrote:
>
> http://techblog.molindo.at/2008/08/wicket-interface-speed-up-caching-resources-forever.html
>
> -igor
>
>
I'm not quite sure if it wraps the case of generating sessionless url's to
static resources when url rewriting
is used to keep track of the session instead of cookies.
My original intent for the first post in this thread was to point out the
fact that the resources such as css or javascript libraries (that never ever
differ in content regardless of the session such as wicket-event.js) indeed
do get cached by the browsers, but due to the fact that it is the url that
is the key for the cache, another request from the same browser but within
another session results in a "miss" in a cache and the resource gets
retrieved from the server again and put in the cache (for not being used
ever again outside of the current session). Just consider getting all java
scripts again and again on each subsequent logging in to your gmail. With
session tracking based on cookies this never happens.
My original idea to solve this was to use the
HttpServletResponse.encodeUrl() conditionally for generating urls to the
resources put in the output markup. Generated urls that are session scoped
should be passed via this method, but the ones that definitely aren't should
be inlined as-is (thus omiting the call).
Igor was wondering if such a behaviour would be against the servlet specs. I
assure you that it is completely up to you whether you use encodeUrl() or
not when generating urls, as long as you know what you are doing (i.e.
whether this jsessionid suffix is useful or not). Otherwise it would have
been put as a core functionality of the container to rewrite all urls
whenever url rewriting based session tracking was in effect, rather than be
exposed as an API.
Bottomline: Do not append jsessionid (omit the encodeUrl() call) whenever
you know that when such a resource is requested you just ignore the
jsessionid.
regz,
/dd
--
View this message in context: http://www.nabble.com/Wicket%2C-url-rewriting-and-shared-resources-browser-caching-tp20508529p23094714.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Wicket, url rewriting and shared resources browser caching
Posted by Igor Vaynberg <ig...@gmail.com>.
http://techblog.molindo.at/2008/08/wicket-interface-speed-up-caching-resources-forever.html
-igor
On Thu, Apr 16, 2009 at 4:20 AM, the_adam <ad...@gmail.com> wrote:
>
> Sorry for bumping, but this was never resolved and seems like an important
> issue.
>
>
> Jörn Zaefferer-2 wrote:
>>
>> Please stop mixing stateless and static. Thank you.
>>
>
> Let's try not to. Any clue how to serve static content (i.e. javascripts)
> that would be cacheable. I cannot imagine that Wicket team would see a
> situation where i.e. jquery.js included by wickext project wouldn't be
> cacheable as a proper one. In a situation as is all resources served by
> plugins / components can only be cached while the session lasts. I would
> call this as highly undesirable.
> --
> View this message in context: http://www.nabble.com/Wicket%2C-url-rewriting-and-shared-resources-browser-caching-tp20508529p23075867.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: Wicket, url rewriting and shared resources browser caching
Posted by the_adam <ad...@gmail.com>.
Sorry for bumping, but this was never resolved and seems like an important
issue.
Jörn Zaefferer-2 wrote:
>
> Please stop mixing stateless and static. Thank you.
>
Let's try not to. Any clue how to serve static content (i.e. javascripts)
that would be cacheable. I cannot imagine that Wicket team would see a
situation where i.e. jquery.js included by wickext project wouldn't be
cacheable as a proper one. In a situation as is all resources served by
plugins / components can only be cached while the session lasts. I would
call this as highly undesirable.
--
View this message in context: http://www.nabble.com/Wicket%2C-url-rewriting-and-shared-resources-browser-caching-tp20508529p23075867.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Wicket, url rewriting and shared resources browser caching
Posted by Jörn Zaefferer <jo...@googlemail.com>.
Please stop mixing stateless and static. Thank you.
Jörn
On Sat, Nov 15, 2008 at 7:34 PM, Dominik Drzewiecki
<do...@gmail.com> wrote:
> 2008/11/15 Johan Compagner <jc...@gmail.com>:
>> 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 <do...@gmail.com> 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 <ig...@gmail.com>
>>>>
>>>> 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
>>>> <ma...@gmail.com> 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
>>>> > <do...@gmail.com> 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.
>>>> >
>>>
>>
>
Re: Wicket, url rewriting and shared resources browser caching
Posted by Dominik Drzewiecki <do...@gmail.com>.
2008/11/15 Johan Compagner <jc...@gmail.com>:
> 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 <do...@gmail.com> 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 <ig...@gmail.com>
>>>
>>> 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
>>> <ma...@gmail.com> 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
>>> > <do...@gmail.com> 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.
>>> >
>>
>
Re: Wicket, url rewriting and shared resources browser caching
Posted by Johan Compagner <jc...@gmail.com>.
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 <do...@gmail.com> 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 <ig...@gmail.com>
>>
>> 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
>> <ma...@gmail.com> 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
>> > <do...@gmail.com> 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.
>> >
>
Re: Wicket, url rewriting and shared resources browser caching
Posted by Dominik Drzewiecki <do...@gmail.com>.
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 <ig...@gmail.com>
>
> 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
> <ma...@gmail.com> 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
> > <do...@gmail.com> 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.
> >
Re: Wicket, url rewriting and shared resources browser caching
Posted by Igor Vaynberg <ig...@gmail.com>.
unless we dont rewrite resource urls. in which case we will be in
violation of the spec...
-igor
On Fri, Nov 14, 2008 at 3:59 PM, Martijn Dashorst
<ma...@gmail.com> 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
> <do...@gmail.com> 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.
>
Re: Wicket, url rewriting and shared resources browser caching
Posted by Martijn Dashorst <ma...@gmail.com>.
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
<do...@gmail.com> 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.