Page MenuHomePhabricator

MediaWiki API Cache-Control headers are different than MediaWiki's which causes problems for VE users on some browsers
Closed, ResolvedPublic1 Story Points

Description

There are different controls for the Cache-Control headers for the API and MediaWiki's OutputPage. This may have seemed innocuous in the past, but it is causing problems now that VisualEditor is moving page editing to the API.

On my local wiki pages are served with:

Cache-Control: private, must-revalidate, max-age=0

and, when mCacheMode is set to 'private', the default, API responses are sent with:

Cache-Control: private

RFC 2616 says:

private
    Indicates that all or part of the response message is intended for
    a single user ... A private (non-shared) cache MAY cache the response.

and:

A cache MAY be configured to return stale responses without
validation, but only if this does not conflict with any "MUST"-level
requirements concerning cache validation (e.g., a "must-revalidate"
cache-control directive).

and:

If a cache receives a 5xx response while attempting to revalidate an
entry, it MAY either forward this response to the requesting client,
or act as if the server failed to respond. In the latter case, it MAY
return a previously received response unless the cached entry
includes the "must-revalidate" cache-control directive (see section
14.9).

old description:
IE 11 seems to cache faulty parsoid responses.

I had a misconfigured server and, even after I fixed the problem and other browsers were able to continue after clicking "edit", IE didn't even attempt to make a request but just kept showing the alert box with the error message.

Details

Reference
bz72480

Event Timeline

bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz72480.

Not sure how we could work around browser-intentional behaviour like this…

It isn't just caching errors. It looks like it is caching all sorts of responses. I think I've seen this in more than just IE, but I can reliably reproduce it with IE.

Please don't use "MSIE"; we normally call it "Internet Explorer" for clarity.

Like T73119: Pressing Backspace/Delete or creating a heading causes the page to abruptly scroll up on Internet Explorer 11, my client has specified this as an important issue. I'm looking for information on tracking down these issues. Any pointers?

MarkAHershberger renamed this task from VisualEditor: Work around Internet Explorer's caching of Parsoid responses to MediaWiki api Cache-Control headers are different than MediaWiki's. This causes problems for VE users on some browsers..Mar 3 2015, 9:47 PM
MarkAHershberger updated the task description. (Show Details)
MarkAHershberger set Security to None.

Updated description with my findings. I think this shows that while IE's behavior may be different, it isn't out-of-spec, especially given that the urls providing the content for reading are different than the urls providing content for the VisualEditor.

Patch to arrive shortly.

Change 194208 had a related patch set uploaded (by MarkAHershberger):
Browser should clear cache for API responses

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

Change 194208 merged by jenkins-bot:
Browser should clear cache for API responses

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

MarkAHershberger closed this task as Resolved.Mar 12 2015, 12:25 AM
MarkAHershberger claimed this task.

Since this was merged...

Jdforrester-WMF renamed this task from MediaWiki api Cache-Control headers are different than MediaWiki's. This causes problems for VE users on some browsers. to MediaWiki API Cache-Control headers are different than MediaWiki's which causes problems for VE users on some browsers.Mar 29 2015, 11:34 PM
Jdforrester-WMF edited a custom field.