Something is causing the 'ETag' headers produced by the "public"
RESTBase (queried directly from the client) to be mangled or lost.
My theory is that some proxy or browser extension is doing that.
When we detect a bad etag when fetching the page contents, discard
the result and try querying the "private" RESTBase via the MediaWiki
API (similar to what we do on private wikis, except there we talk
directly to Parsoid instead of RESTBase). After I463a84de63, that
returns the etag as part of the payload rather than HTTP headers,
and should pass unharmed through whatever is mangling the data.
Also compare and log the two etags.
Bug: T233320
Change-Id: I2ef0ca872597566f74b650aea71bf3f15747a6d7
Previously, the ve-mw/init/ directory contained two kinds of files:
those that were used when initializing VE, and those that may be
loaded even if VE is not going to be initialized at all. The latter
kind must not use the `ve` global variable.
After moving those files to ve-mw/preinit/ we can enforce this with
.eslintrc.json in that directory. This would have prevented T228684.
(Technically they merely must not use `ve.init`, and may use `ve`,
but that's harder to enforce. We should instead move the few non-init
methods out of `ve`: now, track, trackSubscribe, trackSubscribeAll).
Also, group some files under ve-mw/init/: targets/ now (only)
contains ve.init.mw.Target and its subclasses, apiresponsecache/
now contains ve.init.mw.ApiResponseCache and its subclasses.
Bug: T228684
Change-Id: I945249a27f6a0fa10a432d5c5dc57bc7e0461fd8
2019-10-10 15:15:40 +00:00
Renamed from modules/ve-mw/init/ve.init.mw.ArticleTargetLoader.js (Browse further)
