Reported at enwiki Village Pump:
Firefox and IE are interpreting the response from POST'ing a page preview request as a prohibition on any local caching. This results in the browser reporting "Document expired" if a link on the preview is clicked and then the browser back button is pressed to navigate back to the preview page.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Deskana | T75616 Tracking: API/backend issues blocking Wikipedia app development | |||
| Resolved | Anomie | T32788 Allow triggering of user password reset email via the API | |||
| Open | None | T90925 General authentication improvements for MediaWiki | |||
| Resolved | Anomie | T48179 Allow a challenge stage during authentication | |||
| Open | None | T5709 Refactoring to make external authentication and identity systems easier | |||
| Resolved | Tgr | T43201 UserLoadFromSession considered evil | |||
| Resolved | Anomie | T67493 Session is started by EditAction (problem for extensions using UserLoadFromSession hook) | |||
| Open | Feature | None | T55156 Provide option to force a login session to end within a certain time | ||
| Open | None | T89459 Modernize MediaWiki authentication system (AuthManager) | |||
| Resolved | Anomie | T123451 Deploy SessionManager and bot passwords | |||
| Resolved | bd808 | T124510 Page preview response not being cached for history navigation in 1.27.0-wmf11 |
I've personally lost several edits because it is my usual habit to freely browse around my live edit, and it is the custom to check a wikilink in a preview before saving the edit. I don't know how many others edit like myself, but any level is unacceptable for any other priority than UNBREAK now.
We have reverted all wikis back to 1.27.0-wmf.10 (for other reasons). I have also confirmed that 1.27.0-wmf.10 does not exhibit the "Document expired" issue on the same browser instance and version I reproduced it with before. Based on this I'm going to reduce the severity to high. This should still be considered a blocker to 1.27.0-wmf11 returning to wikis other than the test wikis next week.
1.27.0-wmf.10 also sends the same Cache-Control header, so that is not the cause of the problem seen under 1.27.0-wmf11.
Here are the full headers I'm seeing via firebug for the POST under 1.27.0-wmf10 for future comparison:
Accept-Ranges bytes Age 0 Cache-Control private, s-maxage=0, max-age=0, must-revalidate Content-Encoding gzip Content-Language en Content-Length 18239 Content-Type text/html; charset=UTF-8 Date Sat, 23 Jan 2016 01:57:33 GMT Expires Thu, 01 Jan 1970 00:00:00 GMT Server nginx/1.9.4 Strict-Transport-Security max-age=31536000; includeSubDomains; preload Vary Accept-Encoding,Cookie Via 1.1 varnish, 1.1 varnish X-Cache cp1066 pass+chfp(0), cp1055 frontend pass+chfp(0) X-Content-Type-Options nosniff X-Firefox-Spdy 3.1 X-Frame-Options DENY x-analytics WMF-Last-Access=23-Jan-2016;https=1 x-client-ip 2001:dead::beef x-powered-by HHVM/3.6.5 x-ua-compatible IE=Edge x-varnish 2613757104, 880479794
Cat'n reproduce - production and beta enwiki both do this for me in Firefox (43.0.4, Ubuntu) and neither does in Chrome (48.0.2564.82, Ubuntu).
FWIW in similar situations you can just resubmit (F5 or the submit/try again button) to avoid losing edits.
The behavior in Firefox does not depend on wmf10 vs master but it does depend on whether or not you are logged in. So the underlying issue was probably a session loss.
When live preview was used with FireFox, it neither gave Document Expired nor offered Try Again, you simply lost edits. Also, it was intermittent, at times 80% loss, but mostly 100%. The problem went away immediately with the revert.
I can reproduce the local cache failure in Firefox 43.0.4 on http://en.wikipedia.beta.wmflabs.org with both logged in and anonymous previews.
The likely header difference is Pragma: no-cache which master and 1.27.0-wmf.11 are sending but 1.27.0-wmf.10 is not.
Change 266258 had a related patch set uploaded (by BryanDavis):
Call session_cache_limiter() before starting a session
Change 266258 merged by jenkins-bot:
Call session_cache_limiter() before starting a session
Change 266425 had a related patch set uploaded (by BryanDavis):
Call session_cache_limiter() before starting a session
Change 266425 merged by jenkins-bot:
Call session_cache_limiter() before starting a session
Change 267635 had a related patch set uploaded (by BryanDavis):
Disable automatic cache headers associated with starting a session
Change 267635 merged by jenkins-bot:
Disable automatic cache headers associated with starting a session