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.vaynb...@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 ><chr...@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.vaynb...@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 <mgrigo...@apache.org> >>>wrote: >>>> Create a ticket please >>>> >>>> On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman >>>> <chr...@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-unsubscr...@wicket.apache.org >>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Martin Grigorov >>>> jWeekend >>>> Training, Consulting, Development >>>> http://jWeekend.com >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >For additional commands, e-mail: users-h...@wicket.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
