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.
very easy to proove: create a new job just with a single shell command:
date > date.txt
In the worksapce view of this project, the date.txt file seems to be never updated.