Uploaded image for project: 'Wicket'
  1. Wicket
  2. WICKET-5793

Request for static resource creating a session in 6.13.0+

    Details

      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.,

        Attachments

          Activity

            People

            • Assignee:
              bitstorm Andrea Del Bene
              Reporter:
              chrisc Chris Colman
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: