Stale attachment: latest version of attachment is not displayed-downloaded, until you clear browser cache

Date 2004-10-06
JSPWiki version 2.1.111 & current CVS
Criticality BadBug
Status ClosedBug

How to repeat: try to attach a file to a page, revise the file and attach it again. Now, retrieve the attached file, you will get older file rather than latest one.

How to Fix: There is bug in the AttachmentServlet.java. Change in following two lines will make sure that if attachment is modified recently, it will return page otherwise 304 status code.

> BUG: if( lastModifiedTime >= ifModifiedSince ) < FIX: if( lastModifiedTime <= ifModifiedSince )

> BUG: if( lastModified.after(ifModifiedSinceDate) ) > FIX: if( ! (lastModified.after(ifModifiedSinceDate)) )

--YogeshPatel

Fixed in 2.1.113. Thanks! (Move to FixedBugs)

We still have the same problem here, this bugfix does not work. When you do a log.info of ifModifiedSince and lastModifiedTime, the two are always equal so the fix doesn't make any difference. The only workaround seems to be to clear the browser cache and set the caching of the browser to always get a fresh copy but this is not really a solution. This is really a serious problem as users intend to update a document that has in fact already been updated.

--MP

I have a feeling you are using IE? IE has some issues with aggressive caching. Really, the only possibility I can see is to set a no-cache directive whenever an attachment is fetched (which will cause some trouble). One possibility is to also change IE into "check every time" -mode.

Or perhaps, add the version directly to the filename somehow, because then caches would not be an issue.

-- JanneJalkanen

We use IE indeed but this problem occurs also with Firefox(ver 0.9) and there is not even a possibility to set something like the "check every time" -mode".

-- MP

I'm sorry - I just simply cannot repeat this bug. When I look at the HTTP headers they are completely correct, when uploading and downloading (v2.1.136). Closing it for now (please reopen if you still see this happening - cut and paste the relevant HTTP traffic here (the Firefox LiveHTTPHeaders is wonderful for that).

-- JanneJalkanen, 10-Jan-05

Could the Bug Firefox Does Not Like Escaped Char In URL be a reason?

-- JanneJalkanen 27-Jan-05

Opening this again... I don't know what is going on.

-- JanneJalkanen, 29-Mar-05

BTW, I have seen this bug in both Firefox and IE. In IE you do get the correct version once you clear your cache. Incidentally, if you go to the attachment info page, and click on the latest version, you do get the right version as well.

-- JakeVogelaar, 30-Mar-05

If you download from the info page, it makes sense, because then the URL is different (and unique for each version). The browser has not seen the URL before, so therefore it downloads things directly and not from the cache.

Could someone who can replicate this bug please post the HTTP traffic, both the request and the response here? The LiveHTTPHeaders Firefox extension should help, if you don't know how...

-- JanneJalkanen, 30-Mar-05

I tested it again with the tool mentioned above and Firefox 1.0.2. The headers showed that the latest version was get correctly but Firefox was showing the latest version only after an explicit refresh of the page.

-- MP, 04-Apr-05

I made a small change in 2.1.160; please check if it helps.

-- JanneJalkanen, 05-Apr-2005

Works OK now, even on IE with caching of the browser on 'Automatically' and 'Remove temp files when closing browser' checked off !

-- MP, 05-Apr-05

Works for me as well. Thanks!

-- JakeVogelaar, 05-Apr-05

It seems that removing the Expires-header did it. There's a slight problem now: for every attachment a new HTTP request is created, which does create some extra load. Luckily AttachmentServlet can generate 304s now, so it's not that bad... However, for the future, it might make sense to change the URL slightly (by adding a nonce or the version number) whenever a new attachment is uploaded; this would allow the UA to immediately notice that the attachment has changed. However, if the URL has not changed, the attachment would obviously still be the same. That would generate some extra HTTP traffic as well, but it would allow for efficient caching of attachments.

Closing this bug.

-- JanneJalkanen, 06-Apr-05

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-15) was last changed on 06-Apr-2005 09:06 by Administrator