[WICKET-5793] Request for static resource creating a session in 6.13.0+

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 6.13.0, 7.0.0-M4
• Fix Version/s: 7.0.0-M5, 6.19.0
• Component/s: wicket
• Labels: searchengines seo session
• Assignee: Andrea Del Bene
• Reporter: Chris Colman
• Created: 23/Dec/14 21:49
• Updated: 31/Jan/15 01:36
• Resolved: 14/Jan/15 21:48

Description

Up to version 6.12.0 we were not seeing any session being established when static resources were being requested - which is desirable because often search engines will hit thousands of times a day and most don't use cookies or session rewriting so we end up creating a new session for every static resource request that a search engine makes and that just blows out the number of sessions.

We use:

// Use message digest over resource content for resource caching
// cache the version information for the lifetime of the application
IResourceVersion resourceVersion = new CachingResourceVersion(new MessageDigestResourceVersion());

// cache resource with a version string in the filename
IResourceCachingStrategy cachingStrategy =
new
FilenameWithVersionResourceCachingStrategy("ver-static",
resourceVersion);

resourceSettings.setCachingStrategy(cachingStrategy);

and this worked fine up to version 6.12.0 where the code for FilenameWithVersionResourceCachingStrategy.decorateReponse was:

/**

• set resource caching to maximum and set cache-visibility to 'public'
• @param response
  */
  @Override
  public void
  decorateResponse(AbstractResource.ResourceResponse response, IStaticCacheableResource resource) { response.setCacheDurationToMaximum(); response.setCacheScope(WebResponse.CacheScope.PUBLIC); }

Unfortunately in 6.13.0+ this code became:

/**

• set resource caching to maximum and set cache-visibility to 'public'
• @param response
  */
  @Override
  public void
  decorateResponse(AbstractResource.ResourceResponse response, IStaticCacheableResource resource)
  {
  String requestedVersion = RequestCycle.get().getMetaData(URL_VERSION);
  • • • > String calculatedVersion =
        this.resourceVersion.getVersion(resource); < ------------
        if (calculatedVersion != null &&
        calculatedVersion.equals(requestedVersion)) { response.setCacheDurationToMaximum(); response.setCacheScope(WebResponse.CacheScope.PUBLIC); }

        }

So the line marked above calls code that always creates a new session.
You can see the stack of this scenario below:

at
com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
WicketModelExposerApplication.java:157)
at
org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
1569)
at org.apache.wicket.Session.get(Session.java:171)
at
org.apache.wicket.request.resource.PackageResource.getCurrentStyle(Packa
geResource.java:192)
at
org.apache.wicket.request.resource.PackageResource.getCacheableResourceS
tream(PackageResource.java:398)
at
org.apache.wicket.request.resource.PackageResource.getCacheKey(PackageRe
source.java:230)
at
org.apache.wicket.request.resource.caching.version.CachingResourceVersio
n.getVersion(CachingResourceVersion.java:100)
at
org.apache.wicket.request.resource.caching.FilenameWithVersionResourceCa
chingStrategy.decorateResponse(FilenameWithVersionResourceCachingStrateg
y.java:200)

PackageResource.getCurrentStyle() seems to be the culprit.

Does wicket really need to create a session when a static resource is requested?

I hope the answer is no because I think the 6.12.0 approach worked well because it did not create a new session for each static request from a search engine.

Martijn-G said in email group:

It creates a temporary Wicket Session, no http session but it could be avoided.

We end up doing a lot of work in the WicketSession because it is an object and it's typed and we can extend it to hold any interesting pieces we need, such as a reference to the current User object etc.,