Page MenuHomePhabricator

Page preview response not being cached for history navigation in 1.27.0-wmf11
Closed, ResolvedPublic

Description

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.

Event Timeline

bd808 raised the priority of this task from to Needs Triage.
bd808 updated the task description. (Show Details)
bd808 added a subscriber: bd808.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptJan 23 2016, 12:48 AM
bd808 set Security to None.
Cpiral added a subscriber: Cpiral.Jan 23 2016, 1:09 AM

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.

Cpiral triaged this task as Unbreak Now! priority.Jan 23 2016, 1:09 AM
bd808 lowered the priority of this task from Unbreak Now! to High.Jan 23 2016, 1:55 AM

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
bd808 renamed this task from "Cache-Control: private, s-maxage=0, max-age=0, must-revalidate" header returned on page preview to Page preview response not being cached for history navigation in 1.27.0-wmf11.Jan 23 2016, 2:01 AM
bd808 updated the task description. (Show Details)
Tgr added a subscriber: Tgr.Jan 23 2016, 7:11 PM

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.

Tgr added a comment.Jan 23 2016, 7:14 PM

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

https://gerrit.wikimedia.org/r/266258

Change 266258 merged by jenkins-bot:
Call session_cache_limiter() before starting a session

https://gerrit.wikimedia.org/r/266258

Change 266425 had a related patch set uploaded (by BryanDavis):
Call session_cache_limiter() before starting a session

https://gerrit.wikimedia.org/r/266425

Fixed in master and backport for 1.27.0-wmf.11 queued for tomorrow's redeploy.

Restricted Application added a project: User-bd808. · View Herald TranscriptJan 26 2016, 1:25 AM
bd808 closed this task as Resolved.Jan 26 2016, 2:04 AM

Change 266425 merged by jenkins-bot:
Call session_cache_limiter() before starting a session

https://gerrit.wikimedia.org/r/266425

Change 267635 had a related patch set uploaded (by BryanDavis):
Disable automatic cache headers associated with starting a session

https://gerrit.wikimedia.org/r/267635

bd808 moved this task from To Do to Done on the User-bd808 board.Feb 1 2016, 3:28 PM

Change 267635 merged by jenkins-bot:
Disable automatic cache headers associated with starting a session

https://gerrit.wikimedia.org/r/267635

bd808 moved this task from Done to Archive on the User-bd808 board.Feb 21 2016, 8:53 PM