TWikiPreferences advises to setup HTTP-EQUIV tag for edit:

• http-equiv meta tags for edit script. Example to expire immediately:
  Set HTTP_EQUIV_ON_EDIT = <meta http-equiv="Expires" content="%GMTIME{"$day $month, $year - $hour:$min:$sec"}% GMT">
  • Please don't use this setting for cache control headers, particularly on Edit, as it causes BackFromPreviewLosesText - see below for details. -- RichardDonkin

Search on google gives a page (http://vancouver-webpages.com/META/metatags.detail.html) suggesting slightly different format: <META HTTP-EQUIV="expires" CONTENT="Wed, 26 Feb 1997 08:21:57 GMT">

Is it a bug? What is correct format?

Obviously I am reporting it because I found possible error: looks like IE ignores difference and expires page immediately, but Mozilla Firebird does not (and when editing I'll got previous page, which messes edit tremendously (and I lost big chunk of credibility and trust).

• Am I doing something wrong?
• How to generate day of the week?
• What is the proper format?

• And again BetterDefaults: Why "expire immediately" is not set up by default for edit? Is it not reasonable to expect? Is easier way to do it?

I read GMTIME in TWikiVariables, looks like no way to set up day-of-the-week. Gurus, please help.

I found in ViewAfterSaveCachesOldPage Colas advised to use content="Monday, 1-Jan-99 01:01:01 GMT" did not helped either. Is it a bug in Firebird, then?

• Colas' suggestion was not a good idea, have deleted from that page -- RD

-- PeterMasiar - 29 Jun 2003

I've created a patch for other reasons that might help. This isn't a proper patch file since I didn't think it worth releasing, but since you've got a need here's the diffs - these have been hacked about a bit, and won't work through patch so you'll need to do this by hand. It works though. ("-" lines are old lines in BeijingRelease, "+" lines are those that either need adding or changing.) If I get a chance I'll do a proper patch for these.

--- ../../../../../TWikiReleases/20030201/lib/TWiki.pm  2003-02-02 00:55:21.000000000 +0000
+++ TWiki.pm    2003-06-14 19:56:32.000000000 +0100
 # Global variables:
 use vars qw(
-       @isoMonth @weekDay
+       @isoMonth @weekDay @longMonths @dayWeek
        $TranslationToken %mon2num $isList @listTypes @listElements
@@ -122,6 +123,8 @@
 # (new variables must be declared in "use vars qw(..)" above)
 @isoMonth = ( "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" );
 @weekDay = ("Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat");
+@dayWeek      = qw(Sunday Monday Tuesday Wednesday Thursday Friday Saturday);
+@longMonths   = qw(January February March April May June July August September October November December);
@@ -962,7 +967,7 @@
 {
     my( $theTime, $theFormat ) = @_;

-    my( $sec, $min, $hour, $mday, $mon, $year, $wday ) = gmtime( $theTime );
+    my( $sec, $min, $hour, $mday, $mon, $year, $wday, $yday ) = gmtime( $theTime );

     if( $theFormat ) {
         $year += 1900;
@@ -1507,14 +1535,16 @@
     my $time = time();

     if( $format ) {
-        my( $sec, $min, $hour, $day, $mon, $year ) = gmtime( $time );
-          ( $sec, $min, $hour, $day, $mon, $year ) = localtime( $time ) if( $theZone eq "servertime"
);
+        my( $sec, $min, $hour, $day, $mon, $year, $wday, $yday) = gmtime( $time );
+          ( $sec, $min, $hour, $day, $mon, $year, $wday, $yday ) = localtime( $time ) if( $theZone eq "servertime" );
         $value = $format;
         $value =~ s/\$sec[o]?[n]?[d]?[s]?/sprintf("%.2u",$sec)/geoi;
         $value =~ s/\$min[u]?[t]?[e]?[s]?/sprintf("%.2u",$min)/geoi;
         $value =~ s/\$hou[r]?[s]?/sprintf("%.2u",$hour)/geoi;
         $value =~ s/\$day/sprintf("%.2u",$day)/geoi;
         $value =~ s/\$mon[t]?[h]?/$isoMonth[$mon]/goi;
+        $value =~ s/\$longmonth/$longMonths[$mon]/goi;
+        $value =~ s/\$weekday/$weekDay[$wday]/goi;
+        $value =~ s/\$wday/$dayWeek[$wday]/goi;
         $value =~ s/\$mo/sprintf("%.2u",$mon+1)/geoi;

I'd done this because I wanted something pretty.

-- MichaelSparks - 30 Jun 2003

It's not very useful to set HTTP_EQUIV_ON_EDIT, since most proxy caches ignore it and it was originally put in to address RefreshEditPage - however, HTTP_EQUIV_ON_EDIT doesn't actually fix this (now fixed in TWiki core), and it actually causes BackFromPreviewLosesText on some browsers.

Since HTTP_EQUIV_ON_EDIT has caused loss of edits (and credibility!), maybe we should just delete this, or at least unset it by default? Having an example of setting this to immediate expiry is rather dangerous, it just encourages people to mess things up...

I am not too happy about having two conflicting ways of doing cache control - see BrowserAndProxyCacheControl for background and BackFromPreviewLosesText for discussion.

-- RichardDonkin - 30 Jun 2003

So how I do make my edit page expire (avoid caching) without HTTP_EQUIV_ON_EDIT? If this was a cure for BackFromPreviewLosesText, the cure is much worse than disease: now every time when I edit I lose previous edit.

I checked this bug using KwikiWiki - no problem. So it is a Twiki bug. It was not here in previous version, and my whole point of upgrading was to get rid of the bug. I mean, some Twiki settings allowed me to enable edit cache, and i have no idea how to disable it. If somebody wants to help me with this, I'll appreciate it a lot. It's very urgent for me. I just created a Twiki wiki for CGI::Application maillist...

-- PeterMasiar - 30 Jun 2003

Are you using the default templates or something from someone else? If from someone else, what does your edit URL look like? If it doesn't look like: http://twiki.org/cgi-bin/edit/Codev/BugInHttpEquiv?t=1057066704 ie have ?t=number on the end it sounds like you're using a broken skin. One of my handrolled skins was using the approach of %SCRIPTURL%/bin/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%, but this is no longer valid - if you're not, you should be using %EDITTOPIC% or else you get exactly the problem you're describing.

(The question mark marks the page almost inherently uncacheable by many things with caches in)

• And the constantly changing value after ?t= makes the page truly uncacheable except by the most aggressive (and probably uncommon) proxy caches. -- RichardDonkin

-- MichaelSparks - 01 Jul 2003

If skin writers are getting this wrong this strengthens the case for AdministratorControlledWorkflow

• _The issue isn't whether the next page is Preview or Save, it's that the user can hit Edit a second time in the same session on a given page (RefreshEditPage), or can hit the Back button to the Edit page (BackFromPreviewLosesText).

-- MartinCleaver - 01 Jul 2003

This was it! Michael, you are the man! I should use %EDITTOPIC%. I commented my experience on SkinFAQ page to help the next guy.

-- PeterMasiar - 01 Jul 2003

The bug Peter is talking about is RefreshEditPage - this is one of the key bugs fixed in TWikiRelease01Feb2003, but the details weren't fully documented for skin writers since I was rather busy at the time of release... %EDITTOPIC% is the solution; those interested in skins may want to comment on RefreshEditPage since its use by skins could be improved.

BackFromPreviewLosesText only affects IE5/IE6 (InternetExplorer); RefreshEditPage mainly affects OperaBrowser and MozillaBrowser (and cousins). The fixes for these bugs were separate but they are often confused.

I've set this to BugRejected - IMO the real solution is to strongly discourage attempted cache control using HTTP_EQUIV_ON_EDIT and related options, since they were added erroneously at a time when people thought they would help with RefreshEditPage. In any case, most proxy caches ignore these settings and only use HTTP headers for cache control - see BrowserAndProxyCacheControl. I've updated TWikiPreferences accordingly. Any comments on this are welcome of course

It's fine to use HTTP_EQUIV_* to add non-caching-related META information to the HTML document, but META tags aren't that good for other purposes either.

I've also deleted the rather dangerous and previously untested suggestion from ViewAfterSaveCachesOldPage since it recreates BackFromPreviewLosesText on all browsers! Just when I thought that bug was fixed...

-- RichardDonkin - 01 Jul 2003