You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Chris Colman <ch...@stepaheadsoftware.com> on 2012/01/11 11:36:41 UTC
Javascript resources and jsessionid
I realize that the servlet container is responsible for URL rewriting
and hence adding the jsessionid but I was after an opinion:
Is it right that Javascript resources get URLs rewritten to include the
jsessionid when search engines access a website?
(And indeed for normal users on their first visit to the site).
Eg.,
<script type="text/javascript"
src="wicket/resource/org.apache.wicket.extensions.ajax.markup.html.modal
.ModalWindow/res/modal-ver-1326193494000.js;jsessionid=3E45F45F056AF2BCF
CFD030B489F832A"></script>
I guess for search engines it doesn't matter as they won't be
downloading the .js anyway - the jsessionid just adds extra clutter to
the HTML - but for normal users with cookies enabled it could cause the
.js downloaded after a new session is created to be redownloaded when
the next page is requested because at that stage the server would have
established that the client supports cookies and so would not render
subsequent pages with jsessionidS suffixed to the .js references.
Depending on how smart the browser's cache is it might see the jsession
suffixed .js and the clean .js as two separate resources and do a second
download of the .js.
Hmmm, interesting.
Again, this is not strictly a Wicket issue but I'd be interested to know
what others think about this.
Yours sincerely,
Chris Colman
Pagebloom Team Leader,
Step Ahead Software
pagebloom - your business & your website growing together
Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120
Email: chrisc@stepahead.com.au <ma...@stepahead.com.au>
Website:
http://www.pagebloom.com <blocked::http://www.pagebloom.com/>
http://develop.stepaheadsoftware.com
<blocked::http://develop.stepaheadsoftware.com/>
Re: Turning off one-pass-render for a single page
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
See org.apache.wicket.RestartResponseException#RestartResponseException
You need
public RestartResponseException(final IPageProvider pageProvider,
final RedirectPolicy redirectPolicy)
constructor with RedirectPolicy#NEVER_REDIRECT as second parameter.
On Fri, Jan 13, 2012 at 12:10 AM, Matthew Pennington
<ma...@profounddecisions.co.uk> wrote:
> I have an application which needs to accept a POST request from an outside
> server, to confirm payment. I don't want to break the default wicket render
> strategy (REDIRECT_TO_BUFFER) which is serving to give the users a nicer
> experience than ONE_PASS_RENDER would, however, the external service is not
> happy with the 302, and keeps retrying until it gives up.
>
> Is there some sensible way that I can tell wicket to use ONE_PASS_RENDER for
> only the specific page that handles this request?
>
> Matt Pennington
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Turning off one-pass-render for a single page
Posted by Matthew Pennington <ma...@profounddecisions.co.uk>.
I have an application which needs to accept a POST request from an
outside server, to confirm payment. I don't want to break the default
wicket render strategy (REDIRECT_TO_BUFFER) which is serving to give the
users a nicer experience than ONE_PASS_RENDER would, however, the
external service is not happy with the 302, and keeps retrying until it
gives up.
Is there some sensible way that I can tell wicket to use ONE_PASS_RENDER
for only the specific page that handles this request?
Matt Pennington
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
I ran a quickstart with a very simple standard link and an AJAX link on a page and using yesterday's 1.5-x HEAD.
The .js resources included in the <head> all had the jsessionid suffix on the first hit from the browser.
>-----Original Message-----
>From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
>Sent: Friday, 13 January 2012 8:13 AM
>To: users@wicket.apache.org
>Subject: Re: Javascript resources and jsessionid
>
>i remember this being fixed in 1.5 after the resource refactor...
>
>-igor
>
>On Thu, Jan 12, 2012 at 12:54 PM, Chris Colman
><ch...@stepaheadsoftware.com> wrote:
>> Yes, I have vague memories of this issue coming up a long time ago in
>1.4.x and at the time I thought it was dealt with but maybe there was a
>problem with its implementation or maybe it regressed somehow.
>>
>>>-----Original Message-----
>>>From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
>>>Sent: Friday, 13 January 2012 3:15 AM
>>>To: users@wicket.apache.org
>>>Subject: Re: Javascript resources and jsessionid
>>>
>>>for packaged resources we should not be adding jsessionid i dont think...
>>>
>>>-igor
>>>
>>>On Thu, Jan 12, 2012 at 1:56 AM, Martin Grigorov <mg...@apache.org>
>>>wrote:
>>>> Create a ticket please
>>>>
>>>> On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman
>>>> <ch...@stepaheadsoftware.com> wrote:
>>>>> I just checked with 1.5.x and for stateless pages all bookmarkable
>page
>>>>> links do not incur the jsessionid suffix for a non cookie client. Once
>>>>> an Ajax link is added to the page however the jsessionid suffix
>appears
>>>>> on all links which makes sense as the page is no longer stateless once
>>>>> Ajax gets involved.
>>>>>
>>>>> To summarize:
>>>>>
>>>>> I guess there's two completely separate issues surrounding jsessionid:
>>>>>
>>>>> 1. A jsessionid is added to package resource links, most of which are
>>>>> static don't need session info for them to be rendered. For a new
>>>>> session in a browser with cookies enabled this causes a 'double load'
>of
>>>>> every package resource. If the user revisits the site after their
>>>>> session has expired then another download of the package resources
>will
>>>>> occur (because they have a different jsessionid suffix)
>>>>>
>>>>> Possible solution: Wicket always renders stateless resources without
>any
>>>>> jsessionid regardless of whether the page is stateful or stateless.
>When
>>>>> servicing a request for a resource without a jsessionid Wicket does
>not
>>>>> attempt to establish a session which avoids creating a Session on
>every
>>>>> stateless resource request.
>>>>>
>>>>> 2. To improve SEO search engine crawlers should see only stateless
>pages
>>>>> so that the jsessionid never appears in any links. Wicket seems to
>work
>>>>> well in this regard already. The tricky part is to create stateless
>>>>> pages in the first place ;)
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>> I'm trying to think of any resources we have mounted that *do* need a
>> session. I'm pretty sure they're all static package resources.
>>
>> Does Wicket itself mount non static references that would be mounted
at
>> /wicket/resource ?
>
>Wicket doesn't mount anything by itself. Your code initiates such
mounting.
I realize the mounts Wicket makes are side effects of a developer adding
things like Ajax links etc., What I'm wondering is if any of these side
effects could mount a non static resource at /wicket/resource or would
that only occur if the developer explicitly mounted non static
resources.
>
>>
>>>-----Original Message-----
>>>From: Martin Grigorov [mailto:mgrigorov@apache.org]
>>>Sent: Tuesday, 17 January 2012 7:20 AM
>>>To: users@wicket.apache.org
>>>Subject: Re: Javascript resources and jsessionid
>>>
>>>Another approach is to mount explicitly all your resources which you
>>>think need the session.
>>>This way you can exclude /wicket/resource/... in your filter.
>>>
>>>On Mon, Jan 16, 2012 at 9:18 PM, Martin Grigorov
<mg...@apache.org>
>>>wrote:
>>>> See
>>>org.apache.wicket.request.mapper.BasicResourceReferenceMapper#mapHand
le
>> r
>>>>
>>>> All IStaticCacheableResource are passed to
>>>>
>>>org.apache.wicket.request.resource.caching.IResourceCachingStrategy#d
ec
>> orat
>>>eUrl.
>>>> There you can tag them as you wish.
>>>>
>>>> On Mon, Jan 16, 2012 at 9:09 PM, Chris Colman
>>>> <ch...@stepaheadsoftware.com> wrote:
>>>>> JIRI issue 4334 has fixed this now which is great.
>>>>>
>>>>> The next issue is that while Wicket is able to avoid establishing
a
>>>>> session for requests for package resources it would be good if
their
>> URL
>>>>> made it easy for other filters (eg., Open Persistence Provider in
>> View)
>>>>> to also ignore them to allow them to avoid establishing a session
>> also.
>>>>>
>>>>> If IStaticCacheableResource resources had a distinctive mount path
>> we
>>>>> could easily configure filters to ignore them.
>>>>>
>>>>> For example if all IStaticCacheableResourceS were mounted under:
>>>>>
>>>>> /wicket/resource/static
>>>>>
>>>>> we could easily configure third party filters to ignore them.
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>
>>>
>>>
>>>--
>>>Martin Grigorov
>>>jWeekend
>>>Training, Consulting, Development
>>>http://jWeekend.com
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
>--
>Martin Grigorov
>jWeekend
>Training, Consulting, Development
>http://jWeekend.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Javascript resources and jsessionid
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Jan 16, 2012 at 9:25 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> I'm trying to think of any resources we have mounted that *do* need a
> session. I'm pretty sure they're all static package resources.
>
> Does Wicket itself mount non static references that would be mounted at
> /wicket/resource ?
Wicket doesn't mount anything by itself. Your code initiates such mounting.
>
>>-----Original Message-----
>>From: Martin Grigorov [mailto:mgrigorov@apache.org]
>>Sent: Tuesday, 17 January 2012 7:20 AM
>>To: users@wicket.apache.org
>>Subject: Re: Javascript resources and jsessionid
>>
>>Another approach is to mount explicitly all your resources which you
>>think need the session.
>>This way you can exclude /wicket/resource/... in your filter.
>>
>>On Mon, Jan 16, 2012 at 9:18 PM, Martin Grigorov <mg...@apache.org>
>>wrote:
>>> See
>>org.apache.wicket.request.mapper.BasicResourceReferenceMapper#mapHandle
> r
>>>
>>> All IStaticCacheableResource are passed to
>>>
>>org.apache.wicket.request.resource.caching.IResourceCachingStrategy#dec
> orat
>>eUrl.
>>> There you can tag them as you wish.
>>>
>>> On Mon, Jan 16, 2012 at 9:09 PM, Chris Colman
>>> <ch...@stepaheadsoftware.com> wrote:
>>>> JIRI issue 4334 has fixed this now which is great.
>>>>
>>>> The next issue is that while Wicket is able to avoid establishing a
>>>> session for requests for package resources it would be good if their
> URL
>>>> made it easy for other filters (eg., Open Persistence Provider in
> View)
>>>> to also ignore them to allow them to avoid establishing a session
> also.
>>>>
>>>> If IStaticCacheableResource resources had a distinctive mount path
> we
>>>> could easily configure filters to ignore them.
>>>>
>>>> For example if all IStaticCacheableResourceS were mounted under:
>>>>
>>>> /wicket/resource/static
>>>>
>>>> we could easily configure third party filters to ignore them.
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>
>>
>>
>>--
>>Martin Grigorov
>>jWeekend
>>Training, Consulting, Development
>>http://jWeekend.com
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
I'm trying to think of any resources we have mounted that *do* need a
session. I'm pretty sure they're all static package resources.
Does Wicket itself mount non static references that would be mounted at
/wicket/resource ?
>-----Original Message-----
>From: Martin Grigorov [mailto:mgrigorov@apache.org]
>Sent: Tuesday, 17 January 2012 7:20 AM
>To: users@wicket.apache.org
>Subject: Re: Javascript resources and jsessionid
>
>Another approach is to mount explicitly all your resources which you
>think need the session.
>This way you can exclude /wicket/resource/... in your filter.
>
>On Mon, Jan 16, 2012 at 9:18 PM, Martin Grigorov <mg...@apache.org>
>wrote:
>> See
>org.apache.wicket.request.mapper.BasicResourceReferenceMapper#mapHandle
r
>>
>> All IStaticCacheableResource are passed to
>>
>org.apache.wicket.request.resource.caching.IResourceCachingStrategy#dec
orat
>eUrl.
>> There you can tag them as you wish.
>>
>> On Mon, Jan 16, 2012 at 9:09 PM, Chris Colman
>> <ch...@stepaheadsoftware.com> wrote:
>>> JIRI issue 4334 has fixed this now which is great.
>>>
>>> The next issue is that while Wicket is able to avoid establishing a
>>> session for requests for package resources it would be good if their
URL
>>> made it easy for other filters (eg., Open Persistence Provider in
View)
>>> to also ignore them to allow them to avoid establishing a session
also.
>>>
>>> If IStaticCacheableResource resources had a distinctive mount path
we
>>> could easily configure filters to ignore them.
>>>
>>> For example if all IStaticCacheableResourceS were mounted under:
>>>
>>> /wicket/resource/static
>>>
>>> we could easily configure third party filters to ignore them.
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>
>
>
>--
>Martin Grigorov
>jWeekend
>Training, Consulting, Development
>http://jWeekend.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Javascript resources and jsessionid
Posted by Martin Grigorov <mg...@apache.org>.
Another approach is to mount explicitly all your resources which you
think need the session.
This way you can exclude /wicket/resource/... in your filter.
On Mon, Jan 16, 2012 at 9:18 PM, Martin Grigorov <mg...@apache.org> wrote:
> See org.apache.wicket.request.mapper.BasicResourceReferenceMapper#mapHandler
>
> All IStaticCacheableResource are passed to
> org.apache.wicket.request.resource.caching.IResourceCachingStrategy#decorateUrl.
> There you can tag them as you wish.
>
> On Mon, Jan 16, 2012 at 9:09 PM, Chris Colman
> <ch...@stepaheadsoftware.com> wrote:
>> JIRI issue 4334 has fixed this now which is great.
>>
>> The next issue is that while Wicket is able to avoid establishing a
>> session for requests for package resources it would be good if their URL
>> made it easy for other filters (eg., Open Persistence Provider in View)
>> to also ignore them to allow them to avoid establishing a session also.
>>
>> If IStaticCacheableResource resources had a distinctive mount path we
>> could easily configure filters to ignore them.
>>
>> For example if all IStaticCacheableResourceS were mounted under:
>>
>> /wicket/resource/static
>>
>> we could easily configure third party filters to ignore them.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Javascript resources and jsessionid
Posted by Martin Grigorov <mg...@apache.org>.
See org.apache.wicket.request.mapper.BasicResourceReferenceMapper#mapHandler
All IStaticCacheableResource are passed to
org.apache.wicket.request.resource.caching.IResourceCachingStrategy#decorateUrl.
There you can tag them as you wish.
On Mon, Jan 16, 2012 at 9:09 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> JIRI issue 4334 has fixed this now which is great.
>
> The next issue is that while Wicket is able to avoid establishing a
> session for requests for package resources it would be good if their URL
> made it easy for other filters (eg., Open Persistence Provider in View)
> to also ignore them to allow them to avoid establishing a session also.
>
> If IStaticCacheableResource resources had a distinctive mount path we
> could easily configure filters to ignore them.
>
> For example if all IStaticCacheableResourceS were mounted under:
>
> /wicket/resource/static
>
> we could easily configure third party filters to ignore them.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
JIRI issue 4334 has fixed this now which is great.
The next issue is that while Wicket is able to avoid establishing a
session for requests for package resources it would be good if their URL
made it easy for other filters (eg., Open Persistence Provider in View)
to also ignore them to allow them to avoid establishing a session also.
If IStaticCacheableResource resources had a distinctive mount path we
could easily configure filters to ignore them.
For example if all IStaticCacheableResourceS were mounted under:
/wicket/resource/static
we could easily configure third party filters to ignore them.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Javascript resources and jsessionid
Posted by Igor Vaynberg <ig...@gmail.com>.
i remember this being fixed in 1.5 after the resource refactor...
-igor
On Thu, Jan 12, 2012 at 12:54 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> Yes, I have vague memories of this issue coming up a long time ago in 1.4.x and at the time I thought it was dealt with but maybe there was a problem with its implementation or maybe it regressed somehow.
>
>>-----Original Message-----
>>From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
>>Sent: Friday, 13 January 2012 3:15 AM
>>To: users@wicket.apache.org
>>Subject: Re: Javascript resources and jsessionid
>>
>>for packaged resources we should not be adding jsessionid i dont think...
>>
>>-igor
>>
>>On Thu, Jan 12, 2012 at 1:56 AM, Martin Grigorov <mg...@apache.org>
>>wrote:
>>> Create a ticket please
>>>
>>> On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman
>>> <ch...@stepaheadsoftware.com> wrote:
>>>> I just checked with 1.5.x and for stateless pages all bookmarkable page
>>>> links do not incur the jsessionid suffix for a non cookie client. Once
>>>> an Ajax link is added to the page however the jsessionid suffix appears
>>>> on all links which makes sense as the page is no longer stateless once
>>>> Ajax gets involved.
>>>>
>>>> To summarize:
>>>>
>>>> I guess there's two completely separate issues surrounding jsessionid:
>>>>
>>>> 1. A jsessionid is added to package resource links, most of which are
>>>> static don't need session info for them to be rendered. For a new
>>>> session in a browser with cookies enabled this causes a 'double load' of
>>>> every package resource. If the user revisits the site after their
>>>> session has expired then another download of the package resources will
>>>> occur (because they have a different jsessionid suffix)
>>>>
>>>> Possible solution: Wicket always renders stateless resources without any
>>>> jsessionid regardless of whether the page is stateful or stateless. When
>>>> servicing a request for a resource without a jsessionid Wicket does not
>>>> attempt to establish a session which avoids creating a Session on every
>>>> stateless resource request.
>>>>
>>>> 2. To improve SEO search engine crawlers should see only stateless pages
>>>> so that the jsessionid never appears in any links. Wicket seems to work
>>>> well in this regard already. The tricky part is to create stateless
>>>> pages in the first place ;)
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
Yes, I have vague memories of this issue coming up a long time ago in 1.4.x and at the time I thought it was dealt with but maybe there was a problem with its implementation or maybe it regressed somehow.
>-----Original Message-----
>From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
>Sent: Friday, 13 January 2012 3:15 AM
>To: users@wicket.apache.org
>Subject: Re: Javascript resources and jsessionid
>
>for packaged resources we should not be adding jsessionid i dont think...
>
>-igor
>
>On Thu, Jan 12, 2012 at 1:56 AM, Martin Grigorov <mg...@apache.org>
>wrote:
>> Create a ticket please
>>
>> On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman
>> <ch...@stepaheadsoftware.com> wrote:
>>> I just checked with 1.5.x and for stateless pages all bookmarkable page
>>> links do not incur the jsessionid suffix for a non cookie client. Once
>>> an Ajax link is added to the page however the jsessionid suffix appears
>>> on all links which makes sense as the page is no longer stateless once
>>> Ajax gets involved.
>>>
>>> To summarize:
>>>
>>> I guess there's two completely separate issues surrounding jsessionid:
>>>
>>> 1. A jsessionid is added to package resource links, most of which are
>>> static don't need session info for them to be rendered. For a new
>>> session in a browser with cookies enabled this causes a 'double load' of
>>> every package resource. If the user revisits the site after their
>>> session has expired then another download of the package resources will
>>> occur (because they have a different jsessionid suffix)
>>>
>>> Possible solution: Wicket always renders stateless resources without any
>>> jsessionid regardless of whether the page is stateful or stateless. When
>>> servicing a request for a resource without a jsessionid Wicket does not
>>> attempt to establish a session which avoids creating a Session on every
>>> stateless resource request.
>>>
>>> 2. To improve SEO search engine crawlers should see only stateless pages
>>> so that the jsessionid never appears in any links. Wicket seems to work
>>> well in this regard already. The tricky part is to create stateless
>>> pages in the first place ;)
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Javascript resources and jsessionid
Posted by Igor Vaynberg <ig...@gmail.com>.
for packaged resources we should not be adding jsessionid i dont think...
-igor
On Thu, Jan 12, 2012 at 1:56 AM, Martin Grigorov <mg...@apache.org> wrote:
> Create a ticket please
>
> On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman
> <ch...@stepaheadsoftware.com> wrote:
>> I just checked with 1.5.x and for stateless pages all bookmarkable page
>> links do not incur the jsessionid suffix for a non cookie client. Once
>> an Ajax link is added to the page however the jsessionid suffix appears
>> on all links which makes sense as the page is no longer stateless once
>> Ajax gets involved.
>>
>> To summarize:
>>
>> I guess there's two completely separate issues surrounding jsessionid:
>>
>> 1. A jsessionid is added to package resource links, most of which are
>> static don't need session info for them to be rendered. For a new
>> session in a browser with cookies enabled this causes a 'double load' of
>> every package resource. If the user revisits the site after their
>> session has expired then another download of the package resources will
>> occur (because they have a different jsessionid suffix)
>>
>> Possible solution: Wicket always renders stateless resources without any
>> jsessionid regardless of whether the page is stateful or stateless. When
>> servicing a request for a resource without a jsessionid Wicket does not
>> attempt to establish a session which avoids creating a Session on every
>> stateless resource request.
>>
>> 2. To improve SEO search engine crawlers should see only stateless pages
>> so that the jsessionid never appears in any links. Wicket seems to work
>> well in this regard already. The tricky part is to create stateless
>> pages in the first place ;)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Javascript resources and jsessionid
Posted by Martin Grigorov <mg...@apache.org>.
Create a ticket please
On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> I just checked with 1.5.x and for stateless pages all bookmarkable page
> links do not incur the jsessionid suffix for a non cookie client. Once
> an Ajax link is added to the page however the jsessionid suffix appears
> on all links which makes sense as the page is no longer stateless once
> Ajax gets involved.
>
> To summarize:
>
> I guess there's two completely separate issues surrounding jsessionid:
>
> 1. A jsessionid is added to package resource links, most of which are
> static don't need session info for them to be rendered. For a new
> session in a browser with cookies enabled this causes a 'double load' of
> every package resource. If the user revisits the site after their
> session has expired then another download of the package resources will
> occur (because they have a different jsessionid suffix)
>
> Possible solution: Wicket always renders stateless resources without any
> jsessionid regardless of whether the page is stateful or stateless. When
> servicing a request for a resource without a jsessionid Wicket does not
> attempt to establish a session which avoids creating a Session on every
> stateless resource request.
>
> 2. To improve SEO search engine crawlers should see only stateless pages
> so that the jsessionid never appears in any links. Wicket seems to work
> well in this regard already. The tricky part is to create stateless
> pages in the first place ;)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
I just checked with 1.5.x and for stateless pages all bookmarkable page
links do not incur the jsessionid suffix for a non cookie client. Once
an Ajax link is added to the page however the jsessionid suffix appears
on all links which makes sense as the page is no longer stateless once
Ajax gets involved.
To summarize:
I guess there's two completely separate issues surrounding jsessionid:
1. A jsessionid is added to package resource links, most of which are
static don't need session info for them to be rendered. For a new
session in a browser with cookies enabled this causes a 'double load' of
every package resource. If the user revisits the site after their
session has expired then another download of the package resources will
occur (because they have a different jsessionid suffix)
Possible solution: Wicket always renders stateless resources without any
jsessionid regardless of whether the page is stateful or stateless. When
servicing a request for a resource without a jsessionid Wicket does not
attempt to establish a session which avoids creating a Session on every
stateless resource request.
2. To improve SEO search engine crawlers should see only stateless pages
so that the jsessionid never appears in any links. Wicket seems to work
well in this regard already. The tricky part is to create stateless
pages in the first place ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
As it turns out WicketFilter isn't responsible for directly creating a
session but some code it calls indirectly in BufferedResponseMapper
attempts to locate a sessionId which for some reason, creates a session
if there is none yet:
protected boolean hasBufferedResponse(Url url)
{
String sessionId = getSessionId();
boolean hasResponse = false;
if (Strings.isEmpty(sessionId) == false)
{
hasResponse =
WebApplication.get().hasBufferedResponse(sessionId, url);
}
return hasResponse;
}
It looks like getSessionId() will always cause a session to be created
if none previously existed. Is this necessary or could it just return
empty string if no current session exists?
>I just had a look at the 1.5 WicketFilter source code and it appears
not
>to be creating or finding a Wicket Session at all - which is a good
sign
>- although maybe it's created somewhere else now.
>
>>The only problem is that each package resource request creates a new
>>Wicket Session in WicketFilter.
>>This may be light or heavy operation, depends on the actual Session
>impl.
>>
>>And in WicketFilter we do not know whether this is a request to a
>>package resource or to any other IResource impl which may need the
>>session. We have this info later.
>>
>>On Wed, Jan 11, 2012 at 2:15 PM, Chris Colman
>><ch...@stepaheadsoftware.com> wrote:
>>>>A use case:
>>>>Imagine that the management of the session in a cookie is disabled
in
>>>>the web server config, so jsessionid is always encoded in the url.
>>>>If resources don't have the jsessionid in their url then a new
>>>>temporary Wicket and http sessions will be created and discarded for
>>>>each request.
>>>
>>> In the use case where jsessionid is to be used instead of cookies
>there
>>> is no need for jsessionid to be present in every url generated in a
>page
>>> render. It is only required in urls that will lead to another page
so
>>> that the session id is transitive from one page to another as the
>user
>>> clicks links.
>>>
>>> Urls that are 'dead ends' and will never lead to other pages being
>>> opened don't need this transitive feature and so don't need to carry
>a
>>> jsessionid.
>>>
>>> I can't ever see a need for encodeURL to be called on a package
>resource
>>> URL - it doesn't lead to another page so there is no need to send
>this
>>> 'session DNA' along with URLs to package resources. It should only
>ever
>>> be needed in URLs that can take the user to another page on the
site.
>>>
>>> There's two approaches to avoid sending these jsessionid's along
with
>>> package resource URLs:
>>>
>>> 1. Wicket framework does some smarts and doesn't encode links to
>package
>>> resources.
>>>
>>> 2. Wicket users override newWebResponse and return WebResponse
>instances
>>> that override encodeURL to avoid calling super.encodeURL(url) for
>>> package resource URLs but do it for links to pages on the site.
>>> Obviously this class would have to analyze the URL and get funky
with
>a
>>> lot of nastiness to get it right.
>>>
>>> In http://issues.apache.org/jira/browse/WICKET-2999 Igor's comment
on
>>> 19/8/2010 seems to suggest that approach 1. was taken and that it
was
>>> working in 1.5 but that was 16 months ago ;)
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>>--
>>Martin Grigorov
>>jWeekend
>>Training, Consulting, Development
>>http://jWeekend.com
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>For additional commands, e-mail: users-help@wicket.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
I just had a look at the 1.5 WicketFilter source code and it appears not
to be creating or finding a Wicket Session at all - which is a good sign
- although maybe it's created somewhere else now.
>The only problem is that each package resource request creates a new
>Wicket Session in WicketFilter.
>This may be light or heavy operation, depends on the actual Session
impl.
>
>And in WicketFilter we do not know whether this is a request to a
>package resource or to any other IResource impl which may need the
>session. We have this info later.
>
>On Wed, Jan 11, 2012 at 2:15 PM, Chris Colman
><ch...@stepaheadsoftware.com> wrote:
>>>A use case:
>>>Imagine that the management of the session in a cookie is disabled in
>>>the web server config, so jsessionid is always encoded in the url.
>>>If resources don't have the jsessionid in their url then a new
>>>temporary Wicket and http sessions will be created and discarded for
>>>each request.
>>
>> In the use case where jsessionid is to be used instead of cookies
there
>> is no need for jsessionid to be present in every url generated in a
page
>> render. It is only required in urls that will lead to another page so
>> that the session id is transitive from one page to another as the
user
>> clicks links.
>>
>> Urls that are 'dead ends' and will never lead to other pages being
>> opened don't need this transitive feature and so don't need to carry
a
>> jsessionid.
>>
>> I can't ever see a need for encodeURL to be called on a package
resource
>> URL - it doesn't lead to another page so there is no need to send
this
>> 'session DNA' along with URLs to package resources. It should only
ever
>> be needed in URLs that can take the user to another page on the site.
>>
>> There's two approaches to avoid sending these jsessionid's along with
>> package resource URLs:
>>
>> 1. Wicket framework does some smarts and doesn't encode links to
package
>> resources.
>>
>> 2. Wicket users override newWebResponse and return WebResponse
instances
>> that override encodeURL to avoid calling super.encodeURL(url) for
>> package resource URLs but do it for links to pages on the site.
>> Obviously this class would have to analyze the URL and get funky with
a
>> lot of nastiness to get it right.
>>
>> In http://issues.apache.org/jira/browse/WICKET-2999 Igor's comment on
>> 19/8/2010 seems to suggest that approach 1. was taken and that it was
>> working in 1.5 but that was 16 months ago ;)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
>--
>Martin Grigorov
>jWeekend
>Training, Consulting, Development
>http://jWeekend.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
I can see things like DynamicWebResource might need a session as what it
streams out could depend on session state but most instances of things
like images, .css, .js, etc., are static.
Perhaps some kind of convention could be used in the URL so that the
WicketFilter could quickly and easily tell by looking at the resource
URL which ones are static (no session required) and which are dynamic
(session required).
Certainly most of the IResources in our sites appear to be all static.
>The only problem is that each package resource request creates a new
>Wicket Session in WicketFilter.
>This may be light or heavy operation, depends on the actual Session
impl.
>
>And in WicketFilter we do not know whether this is a request to a
>package resource or to any other IResource impl which may need the
>session. We have this info later.
>
>On Wed, Jan 11, 2012 at 2:15 PM, Chris Colman
><ch...@stepaheadsoftware.com> wrote:
>>>A use case:
>>>Imagine that the management of the session in a cookie is disabled in
>>>the web server config, so jsessionid is always encoded in the url.
>>>If resources don't have the jsessionid in their url then a new
>>>temporary Wicket and http sessions will be created and discarded for
>>>each request.
>>
>> In the use case where jsessionid is to be used instead of cookies
there
>> is no need for jsessionid to be present in every url generated in a
page
>> render. It is only required in urls that will lead to another page so
>> that the session id is transitive from one page to another as the
user
>> clicks links.
>>
>> Urls that are 'dead ends' and will never lead to other pages being
>> opened don't need this transitive feature and so don't need to carry
a
>> jsessionid.
>>
>> I can't ever see a need for encodeURL to be called on a package
resource
>> URL - it doesn't lead to another page so there is no need to send
this
>> 'session DNA' along with URLs to package resources. It should only
ever
>> be needed in URLs that can take the user to another page on the site.
>>
>> There's two approaches to avoid sending these jsessionid's along with
>> package resource URLs:
>>
>> 1. Wicket framework does some smarts and doesn't encode links to
package
>> resources.
>>
>> 2. Wicket users override newWebResponse and return WebResponse
instances
>> that override encodeURL to avoid calling super.encodeURL(url) for
>> package resource URLs but do it for links to pages on the site.
>> Obviously this class would have to analyze the URL and get funky with
a
>> lot of nastiness to get it right.
>>
>> In http://issues.apache.org/jira/browse/WICKET-2999 Igor's comment on
>> 19/8/2010 seems to suggest that approach 1. was taken and that it was
>> working in 1.5 but that was 16 months ago ;)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
>--
>Martin Grigorov
>jWeekend
>Training, Consulting, Development
>http://jWeekend.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Javascript resources and jsessionid
Posted by Martin Grigorov <mg...@apache.org>.
The only problem is that each package resource request creates a new
Wicket Session in WicketFilter.
This may be light or heavy operation, depends on the actual Session impl.
And in WicketFilter we do not know whether this is a request to a
package resource or to any other IResource impl which may need the
session. We have this info later.
On Wed, Jan 11, 2012 at 2:15 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
>>A use case:
>>Imagine that the management of the session in a cookie is disabled in
>>the web server config, so jsessionid is always encoded in the url.
>>If resources don't have the jsessionid in their url then a new
>>temporary Wicket and http sessions will be created and discarded for
>>each request.
>
> In the use case where jsessionid is to be used instead of cookies there
> is no need for jsessionid to be present in every url generated in a page
> render. It is only required in urls that will lead to another page so
> that the session id is transitive from one page to another as the user
> clicks links.
>
> Urls that are 'dead ends' and will never lead to other pages being
> opened don't need this transitive feature and so don't need to carry a
> jsessionid.
>
> I can't ever see a need for encodeURL to be called on a package resource
> URL - it doesn't lead to another page so there is no need to send this
> 'session DNA' along with URLs to package resources. It should only ever
> be needed in URLs that can take the user to another page on the site.
>
> There's two approaches to avoid sending these jsessionid's along with
> package resource URLs:
>
> 1. Wicket framework does some smarts and doesn't encode links to package
> resources.
>
> 2. Wicket users override newWebResponse and return WebResponse instances
> that override encodeURL to avoid calling super.encodeURL(url) for
> package resource URLs but do it for links to pages on the site.
> Obviously this class would have to analyze the URL and get funky with a
> lot of nastiness to get it right.
>
> In http://issues.apache.org/jira/browse/WICKET-2999 Igor's comment on
> 19/8/2010 seems to suggest that approach 1. was taken and that it was
> working in 1.5 but that was 16 months ago ;)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>A use case:
>Imagine that the management of the session in a cookie is disabled in
>the web server config, so jsessionid is always encoded in the url.
>If resources don't have the jsessionid in their url then a new
>temporary Wicket and http sessions will be created and discarded for
>each request.
In the use case where jsessionid is to be used instead of cookies there
is no need for jsessionid to be present in every url generated in a page
render. It is only required in urls that will lead to another page so
that the session id is transitive from one page to another as the user
clicks links.
Urls that are 'dead ends' and will never lead to other pages being
opened don't need this transitive feature and so don't need to carry a
jsessionid.
I can't ever see a need for encodeURL to be called on a package resource
URL - it doesn't lead to another page so there is no need to send this
'session DNA' along with URLs to package resources. It should only ever
be needed in URLs that can take the user to another page on the site.
There's two approaches to avoid sending these jsessionid's along with
package resource URLs:
1. Wicket framework does some smarts and doesn't encode links to package
resources.
2. Wicket users override newWebResponse and return WebResponse instances
that override encodeURL to avoid calling super.encodeURL(url) for
package resource URLs but do it for links to pages on the site.
Obviously this class would have to analyze the URL and get funky with a
lot of nastiness to get it right.
In http://issues.apache.org/jira/browse/WICKET-2999 Igor's comment on
19/8/2010 seems to suggest that approach 1. was taken and that it was
working in 1.5 but that was 16 months ago ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Javascript resources and jsessionid
Posted by Martin Grigorov <mg...@apache.org>.
A use case:
Imagine that the management of the session in a cookie is disabled in
the web server config, so jsessionid is always encoded in the url.
if resources don't have the jsessionid in their url then a new
temporary Wicket and http sessions will be created and discarded for
each request. And their number will be the same as the number of the
resources.
On Wed, Jan 11, 2012 at 1:09 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> I just opened IE and with a new clean session went to our website and
> voila - IE sees the .js files with jsessionid as different to the ones
> without it and so there are two of every .js file required by both the
> home page and the second page I visited.
>
> I imagine if user visits a site on a regular basis but at intervals
> sufficient for the last session to expirre then they will be forced to
> download add an extra set of .js files which will get stored in the
> browser's cache, even though the .js file has not changed.
>
> A URL referencing a .js file should *never* need a jsessionid attached
> to it. It would be good if we could stop that somehow. They have version
> numbers built into their names so the browser will never end up trying
> to use a 'stale' .js file.
>
> Regards
> Chris
>
> ________________________________
>
> From: Chris Colman [mailto:chrisc@stepaheadsoftware.com]
> Sent: Wednesday, 11 January 2012 9:37 PM
> To: users@wicket.apache.org
> Subject: Javascript resources and jsessionid
>
> I realize that the servlet container is responsible for URL rewriting
> and hence adding the jsessionid but I was after an opinion:
>
> Is it right that Javascript resources get URLs rewritten to include the
> jsessionid when search engines access a website?
> (And indeed for normal users on their first visit to the site).
>
> Eg.,
>
> <script type="text/javascript"
> src="wicket/resource/org.apache.wicket.extensions.ajax.markup.html.modal
> .ModalWindow/res/modal-ver-1326193494000.js;jsessionid=3E45F45F056AF2BCF
> CFD030B489F832A"></script>
>
>
> I guess for search engines it doesn't matter as they won't be
> downloading the .js anyway - the jsessionid just adds extra clutter to
> the HTML - but for normal users with cookies enabled it could cause the
> .js downloaded after a new session is created to be redownloaded when
> the next page is requested because at that stage the server would have
> established that the client supports cookies and so would not render
> subsequent pages with jsessionidS suffixed to the .js references.
>
> Depending on how smart the browser's cache is it might see the jsession
> suffixed .js and the clean .js as two separate resources and do a second
> download of the .js.
>
> Hmmm, interesting.
>
> Again, this is not strictly a Wicket issue but I'd be interested to know
> what others think about this.
>
>
> Yours sincerely,
>
> Chris Colman
>
> Pagebloom Team Leader,
> Step Ahead Software
>
>
> pagebloom - your business & your website growing together
>
> Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120
> Email: chrisc@stepahead.com.au <ma...@stepahead.com.au>
> Website:
> http://www.pagebloom.com <blocked::http://www.pagebloom.com/>
> http://develop.stepaheadsoftware.com
> <blocked::http://develop.stepaheadsoftware.com/>
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid - existing JIRA issue fixed in 1.4
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
I noticed this is an existing JIRA issue that was apparently fixed in
1.4 but I'm seeing the double package resources in the cache using an up
to date 1.5-SNAPSHOT.
Existing JIRA issue:
https://issues.apache.org/jira/browse/WICKET-2999
>I just opened IE and with a new clean session went to our website and
>voila - IE sees the .js files with jsessionid as different to the ones
>without it and so there are two of every .js file required by both the
>home page and the second page I visited.
>
>I imagine if user visits a site on a regular basis but at intervals
>sufficient for the last session to expirre then they will be forced to
>download add an extra set of .js files which will get stored in the
>browser's cache, even though the .js file has not changed.
>
>A URL referencing a .js file should *never* need a jsessionid attached
>to it. It would be good if we could stop that somehow. They have
version
>numbers built into their names so the browser will never end up trying
>to use a 'stale' .js file.
>
>Regards
>Chris
>
>________________________________
>
>From: Chris Colman [mailto:chrisc@stepaheadsoftware.com]
>Sent: Wednesday, 11 January 2012 9:37 PM
>To: users@wicket.apache.org
>Subject: Javascript resources and jsessionid
>
>I realize that the servlet container is responsible for URL rewriting
>and hence adding the jsessionid but I was after an opinion:
>
>Is it right that Javascript resources get URLs rewritten to include the
>jsessionid when search engines access a website?
>(And indeed for normal users on their first visit to the site).
>
>Eg.,
>
><script type="text/javascript"
>src="wicket/resource/org.apache.wicket.extensions.ajax.markup.html.moda
l
>.ModalWindow/res/modal-ver-1326193494000.js;jsessionid=3E45F45F056AF2BC
F
>CFD030B489F832A"></script>
>
>
>I guess for search engines it doesn't matter as they won't be
>downloading the .js anyway - the jsessionid just adds extra clutter to
>the HTML - but for normal users with cookies enabled it could cause the
>.js downloaded after a new session is created to be redownloaded when
>the next page is requested because at that stage the server would have
>established that the client supports cookies and so would not render
>subsequent pages with jsessionidS suffixed to the .js references.
>
>Depending on how smart the browser's cache is it might see the jsession
>suffixed .js and the clean .js as two separate resources and do a
second
>download of the .js.
>
>Hmmm, interesting.
>
>Again, this is not strictly a Wicket issue but I'd be interested to
know
>what others think about this.
>
>
>Yours sincerely,
>
>Chris Colman
>
>Pagebloom Team Leader,
>Step Ahead Software
>
>
>pagebloom - your business & your website growing together
>
>Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120
>Email: chrisc@stepahead.com.au <ma...@stepahead.com.au>
>Website:
>http://www.pagebloom.com <blocked::http://www.pagebloom.com/>
>http://develop.stepaheadsoftware.com
><blocked::http://develop.stepaheadsoftware.com/>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Javascript resources and jsessionid
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
I just opened IE and with a new clean session went to our website and
voila - IE sees the .js files with jsessionid as different to the ones
without it and so there are two of every .js file required by both the
home page and the second page I visited.
I imagine if user visits a site on a regular basis but at intervals
sufficient for the last session to expirre then they will be forced to
download add an extra set of .js files which will get stored in the
browser's cache, even though the .js file has not changed.
A URL referencing a .js file should *never* need a jsessionid attached
to it. It would be good if we could stop that somehow. They have version
numbers built into their names so the browser will never end up trying
to use a 'stale' .js file.
Regards
Chris
________________________________
From: Chris Colman [mailto:chrisc@stepaheadsoftware.com]
Sent: Wednesday, 11 January 2012 9:37 PM
To: users@wicket.apache.org
Subject: Javascript resources and jsessionid
I realize that the servlet container is responsible for URL rewriting
and hence adding the jsessionid but I was after an opinion:
Is it right that Javascript resources get URLs rewritten to include the
jsessionid when search engines access a website?
(And indeed for normal users on their first visit to the site).
Eg.,
<script type="text/javascript"
src="wicket/resource/org.apache.wicket.extensions.ajax.markup.html.modal
.ModalWindow/res/modal-ver-1326193494000.js;jsessionid=3E45F45F056AF2BCF
CFD030B489F832A"></script>
I guess for search engines it doesn't matter as they won't be
downloading the .js anyway - the jsessionid just adds extra clutter to
the HTML - but for normal users with cookies enabled it could cause the
.js downloaded after a new session is created to be redownloaded when
the next page is requested because at that stage the server would have
established that the client supports cookies and so would not render
subsequent pages with jsessionidS suffixed to the .js references.
Depending on how smart the browser's cache is it might see the jsession
suffixed .js and the clean .js as two separate resources and do a second
download of the .js.
Hmmm, interesting.
Again, this is not strictly a Wicket issue but I'd be interested to know
what others think about this.
Yours sincerely,
Chris Colman
Pagebloom Team Leader,
Step Ahead Software
pagebloom - your business & your website growing together
Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120
Email: chrisc@stepahead.com.au <ma...@stepahead.com.au>
Website:
http://www.pagebloom.com <blocked::http://www.pagebloom.com/>
http://develop.stepaheadsoftware.com
<blocked::http://develop.stepaheadsoftware.com/>