• Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Critical Critical
    • core
    • None
    • Platform: All, OS: All

      I browse a workspace (in my case on a build slave) and view some generated
      files. Then I re-build the project and try to look at the new generated files.

      Expected: new contents
      Experienced: old contents as seen when I first looked at it

          [JENKINS-272] workspace page delivers out-dated files

          gradopado added a comment -
          • cache cleaned, first access to the file:
            Last-Modified: Fri, 09 Feb 2007 10:19:33 CET
          • page reload:
            If-Modified-Since: Fri, 09 Feb 2007 10:19:33 CET

          HTTP/1.x 304 Not Modified

          • "build now" @ 09.02.2007 10:58:42
          • access file:
            (old contents, no headers sent!)
          • page reload:
            If-Modified-Since: Fri, 09 Feb 2007 10:19:33 CET

          Last-Modified: Fri, 09 Feb 2007 10:58:42 CET

          • "build now" @ 09.02.2007 11:00:23
          • access file:
            (old contents, no headers sent!)
          • page reload:
            If-Modified-Since: Fri, 09 Feb 2007 10:58:42 CET

          Last-Modified: Fri, 09 Feb 2007 11:00:23 CET

          • page reload:
            If-Modified-Since: Fri, 09 Feb 2007 11:00:23 CET

          HTTP/1.x 304 Not Modified

          ---------------------------
          Firefox just doesn't ask for a new file, at least I did not see any header. (I'm
          not an expert in HTTP.) A page reload seems to help. What do you think?

          gradopado added a comment - cache cleaned, first access to the file: Last-Modified: Fri, 09 Feb 2007 10:19:33 CET page reload: If-Modified-Since: Fri, 09 Feb 2007 10:19:33 CET HTTP/1.x 304 Not Modified "build now" @ 09.02.2007 10:58:42 access file: (old contents, no headers sent!) page reload: If-Modified-Since: Fri, 09 Feb 2007 10:19:33 CET Last-Modified: Fri, 09 Feb 2007 10:58:42 CET "build now" @ 09.02.2007 11:00:23 access file: (old contents, no headers sent!) page reload: If-Modified-Since: Fri, 09 Feb 2007 10:58:42 CET Last-Modified: Fri, 09 Feb 2007 11:00:23 CET page reload: If-Modified-Since: Fri, 09 Feb 2007 11:00:23 CET HTTP/1.x 304 Not Modified --------------------------- Firefox just doesn't ask for a new file, at least I did not see any header. (I'm not an expert in HTTP.) A page reload seems to help. What do you think?

          OK, so the issue seems to be that Firefox doesn't even send a request unless you
          hit F5.

          Maybe I need to send another cache control header or something.

          Kohsuke Kawaguchi added a comment - OK, so the issue seems to be that Firefox doesn't even send a request unless you hit F5. Maybe I need to send another cache control header or something.

          Apparently when Last-Modified header is set but no Expires header is set,
          Firefox automatically guesses the effective Expires header value and won't send
          GET with If-Modified-Since until that effective Expires date is reached.

          References:
          http://labs.cybozu.co.jp/blog/kazuho/archives/2006/02/utilizing_cache.php
          http://www.mnot.net/cache_docs/
          (still looking for authoritative source)

          The solution will be to send the Expires header with the same timestamp.

          Kohsuke Kawaguchi added a comment - Apparently when Last-Modified header is set but no Expires header is set, Firefox automatically guesses the effective Expires header value and won't send GET with If-Modified-Since until that effective Expires date is reached. References: http://labs.cybozu.co.jp/blog/kazuho/archives/2006/02/utilizing_cache.php http://www.mnot.net/cache_docs/ (still looking for authoritative source) The solution will be to send the Expires header with the same timestamp.

          Fixed in 1.83.

          Kohsuke Kawaguchi added a comment - Fixed in 1.83.

          gradopado added a comment -

          I've set up a test job in hudson 1.83 which produces a file with a timestamp. It
          should archive all artifacts (the file with timestamp).

          The fix worked only once, then I still got stale files on the "latest artifacts"
          page and on the workspace view also.

          I'll check http headers if needed for your investigation.

          gradopado added a comment - I've set up a test job in hudson 1.83 which produces a file with a timestamp. It should archive all artifacts (the file with timestamp). The fix worked only once, then I still got stale files on the "latest artifacts" page and on the workspace view also. I'll check http headers if needed for your investigation.

              • Issue 390 has been marked as a duplicate of this issue. ***

          Kohsuke Kawaguchi added a comment - Issue 390 has been marked as a duplicate of this issue. ***

          Bumping up the priority since another report was filed for this bug.

          Kohsuke Kawaguchi added a comment - Bumping up the priority since another report was filed for this bug.

          gradopado added a comment -

          I still have to clear the cache of my Firefox in order to get the latest build
          artifacts. I mean when accessing "latestSuccessful", where the URL is always the
          same but the files change.

          Hudson version 1.152

          gradopado added a comment - I still have to clear the cache of my Firefox in order to get the latest build artifacts. I mean when accessing "latestSuccessful", where the URL is always the same but the files change. Hudson version 1.152

          Alan Harder added a comment -

          As far as I can tell, the original bugfix is working correctly. It is not clock
          difference between master-slave that makes a difference, but clock difference
          between where the workspace resides (in this case, slave machine) and the client
          system where your browser is running. If Hudson sends back an Expires header
          for 14:00 but your system thinks it is only 13:57 then for the next couple
          minutes your browser won't even send a HTTP request for that cached file.. but
          once the client system's clock does reach 14:00 then another time clicking that
          link does check with the server and get the latest file content.

          Net effect: you only see old content if:
          a) Your client system's clock in N minutes behind the system where the build runs
          b) A build runs
          c) Within N minutes of when file X is written during that build:
          1) You access file X in the workspace browser
          2) Another build runs
          3) You access file X again

          A lot to happen in that time window.. but, if we do want to avoid this case then
          the Expires header probably should be set even earlier. Rather than matching
          the Last-Modified date, make it even earlier to account for clock differences.
          Unfortunately, Stapler's serveFile method doesn't currently have any way to do
          this.. any expiration value <= 0 just uses the Last-Modified value. Maybe
          stapler should only do this for == 0 (which is what the javadoc says) and use
          the value as a delta for both positive and negative.. then we could pass
          -600000L or something.

          Side note: only Expires header has this problem.. Last-Modified is NOT compared
          to your client system's clock.. your browser remembers this value, and when it
          does send another HTTP request (current time is past Expires time) then it just
          sends that same value in the request, and the SERVER compares that value to the
          current timestamp of file X.

          Alan Harder added a comment - As far as I can tell, the original bugfix is working correctly. It is not clock difference between master-slave that makes a difference, but clock difference between where the workspace resides (in this case, slave machine) and the client system where your browser is running. If Hudson sends back an Expires header for 14:00 but your system thinks it is only 13:57 then for the next couple minutes your browser won't even send a HTTP request for that cached file.. but once the client system's clock does reach 14:00 then another time clicking that link does check with the server and get the latest file content. Net effect: you only see old content if: a) Your client system's clock in N minutes behind the system where the build runs b) A build runs c) Within N minutes of when file X is written during that build: 1) You access file X in the workspace browser 2) Another build runs 3) You access file X again A lot to happen in that time window.. but, if we do want to avoid this case then the Expires header probably should be set even earlier. Rather than matching the Last-Modified date, make it even earlier to account for clock differences. Unfortunately, Stapler's serveFile method doesn't currently have any way to do this.. any expiration value <= 0 just uses the Last-Modified value. Maybe stapler should only do this for == 0 (which is what the javadoc says) and use the value as a delta for both positive and negative.. then we could pass -600000L or something. Side note: only Expires header has this problem.. Last-Modified is NOT compared to your client system's clock.. your browser remembers this value, and when it does send another HTTP request (current time is past Expires time) then it just sends that same value in the request, and the SERVER compares that value to the current timestamp of file X.

          Alan Harder added a comment -

          closing old issue

          Alan Harder added a comment - closing old issue

            Unassigned Unassigned
            gradopado gradopado
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: