Submitted by : simon at: 2003-10-26T21:31:45+00:00 (17 years ago)
Name :
Category : Severity : Status :
Optional subject :  
Optional comment :

This can be seen at the page ThomasWeigert; just click on edit and you will see that the list for patches has disappeared...

DeanGoodmanson, 2002/12/09 01:08 GMT (via web):
The patches showed up for me. :-(

I've seen this before. I think it may be a strange caching issue.

Brute force fixing may make it hard to keep the edit, render clunk, BACK, fix, ... cycle alive.

At the time I thought it was discrepencies between ZMI based edits and standard edits.

SimonMichael, 2002/12/09 17:17 GMT (via web):
I'm pretty sure this is a browser caching bug. I used to see this with mozilla, I would have to shift-reload to see the latest data in the editform, until I changed the caching preference (check page every time ?). I notice the phoenix browser doesn't have this preference and it just works. (Downgraded, recategorized, changed to pending).

Perhaps this should be documented in the FAQ or a known issues page.

ThomasWeigert, 2002/12/09 21:55 GMT (via web):
I am sure this was not browser related, as I restarted my browser before submitting this bug to test. However, I am not seeing this behavior today... lets wait a couple more days and I close if it does not recur...

SimonMichael, 2002/12/09 22:03 GMT (via web):
If it does, also tell us your browser version and whether shift-reloading the editform helps. Thanks.

Mike Beaton, 2003/03/02 11:19 GMT
I think I know what is going on here (I did quite a lot of work on browser caching for my last company...)

The /editform in ZWiki page does not provide any HTTP Expires: headers (or others - there are loads of headers to control this stuff).

This makes for an interesting interaction with IE (the browser I know most about, I'm afraid, but I am 99% sure that something like this will apply to other browsers).

IE is very well behaved concerning HTTP Expiry headers. All those settings in Tools/Internet Options/Temporary Internet Files/Settings... only change the behaviour of IE in cases where it still has discretion because the expires headers aren't there. Therefore, for instance, it is easy to make a page which refreshes every time you access it in IE, even if IE is set to "Check for newer versions of stored pages: Never". (The reason is, it is easy to create pages that IE never does store!)

As editform is in the above category, the default behaviour in IE (with default caching options) is:

Typing /editform at the URL manually only fetches the most recently cached version of the page (browser side) so it will be missing all latest edits.

Clicking on the edit link on the page does fetch the latest version server side, so you will see the latest edits.

In general, it is bad design for a website not to enforce to correct required caching for it's own pages - though there are a lot of possible HTTP caching options and it always far from obvious which the best set are for a given application. I could dredge up from memory what the set is that causes a page to always be refreshed when the user is online, but still available when the user is offline, which is a nice set (as it allows expected Back button operation, etc.)

(There's more stuff going on here, I note using SamSpade? that the /editform page sends an empty ETag?. A non-empty ETag? would be useful here, because then the browser could do a conditional GET.)

Brief description of issue --MichaelBeaton?, 2003/03/02 17:42 GMT
That was the long version. Can I just quickly add the short version:


property change --SimonMichael, 2003/08/02 23:23 GMT reply
Category: other => skins and content

status ? --simon, Sat, 17 Apr 2004 19:42:29 -0700 reply
I never see this, so it's been low priority. What header should I add to editform ?

add no-cache headers --simon, Wed, 21 Apr 2004 10:53:11 -0700 reply
Following Casey's recipe on zopelabs, I've added this to the editform:

  <meta http-equiv="pragma" content="no-cache">
  <dummy tal:attributes="dummy python:request.RESPONSE.setHeader('pragma','no-cache')" />

This is in darcs (no named patch though, an accident). I can't detect any difference with curl, can someone who can reproduce test and confirm this fix ?

add no-cache headers --simon, Wed, 21 Apr 2004 10:56:43 -0700 reply
By the way I did this in the standard skin, not zwiki_plone. I'm not sure how to do it there and will leave it alone unless someone can confirm the problem is also with zwiki_plone/editform. Alternately if you're clear on all these caching issues and can see exactly what is needed, let me know what.

property change --simon, Wed, 21 Apr 2004 10:57:02 -0700 reply
Status: open => pending

property change --simon, Mon, 24 May 2004 23:07:58 -0700 reply
Status: pending => closed