Tapestry
  1. Tapestry
  2. TAPESTRY-1447

Headers are not set appropiately to allow the browser to cache javascript resources.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 5.0.4
    • Fix Version/s: 5.0.5
    • Component/s: None
    • Labels:
      None

      Description

      It seems the T5 asset javascript files (such as prototype,scriptalicous) are not being cached by browsers (tested IE6 and FF).
      Using Firebug and having the server on a slow (= cable modem upload)
      connection shows this problem very well (constant reloading of .js and .css files), with about 2-3s page delay in transferring the .js files. Caching appears to work just fine on application images though, which are also injected via assets (the red fieldmarker X is not cached however).

        Activity

        Hide
        Yann Ramin added a comment -

        It appears that the Resource objects are getting an incorrect Last-Modified header set in the latest snapshot from SVN.

        Hacking ResourceStreamerImpl to use System.currentTimeMillis() when lastModified == 0, and a suitable change in AssetDispatcher.java (to send not modified even when lastmodified == 0) is an ugly workaround but appears to solve the issue.

        Show
        Yann Ramin added a comment - It appears that the Resource objects are getting an incorrect Last-Modified header set in the latest snapshot from SVN. Hacking ResourceStreamerImpl to use System.currentTimeMillis() when lastModified == 0, and a suitable change in AssetDispatcher.java (to send not modified even when lastmodified == 0) is an ugly workaround but appears to solve the issue.
        Hide
        Daniel Gredler added a comment -

        My quick look at this issue suggested that URLChangeTracker tracks changes in milliseconds, while the HTTP headers like Last-Modified have a granularity of seconds. This means that when the browser tells T5 "don't give me this file if it hasn't been modified since...", T5 thinks it has been modified, because its internal timestamp is a couple of hundred milliseconds after the browser-specified time. I'll try to commit a fix to this granularity mismatch when I get a chance.

        Show
        Daniel Gredler added a comment - My quick look at this issue suggested that URLChangeTracker tracks changes in milliseconds, while the HTTP headers like Last-Modified have a granularity of seconds. This means that when the browser tells T5 "don't give me this file if it hasn't been modified since...", T5 thinks it has been modified, because its internal timestamp is a couple of hundred milliseconds after the browser-specified time. I'll try to commit a fix to this granularity mismatch when I get a chance.
        Hide
        Daniel Gredler added a comment -

        The granularity mismatch is fixed in SVN. Give it a try, and if you run into any more header problems, open a new issue and let us know which headers you think are missing or incorrect. Thanks!

        Show
        Daniel Gredler added a comment - The granularity mismatch is fixed in SVN. Give it a try, and if you run into any more header problems, open a new issue and let us know which headers you think are missing or incorrect. Thanks!

          People

          • Assignee:
            Daniel Gredler
            Reporter:
            Yann Ramin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development