Page MenuHomePhabricator

Evaluate ETags in core HTML endpoints
Closed, ResolvedPublic

Description

RESTBase currently emits ETag headers in the following format: "<revision_id>/<TimeUUID>(/stash)?" where revision_id is the ID of the revision for the HTML and TimeUUID is a unique UUID of the HTML render, based on the rendering timestamp. Optional /stash suffix is added for stashed transformation, but we can probably add it if the HTML was added to a stash even for page/revision HTML GET requests with stashing.

A few services using RESTBase might depend on this ETag format, but I do not quite know of any hard dependencies. We should evaluate whether adopting the same format of ETag is wise (TimeUUID might be quite expensive to generate) and either adopt it, or come up with a new format.

The requirements for ETag is that it needs to be unique for each rendering of the page we produce since parsoid's parses are not stable and might differ from render to render. The etag should by itself uniquely identify an entry in parsoid stash. All the normal ETag header guarantees should hold as well.

Event Timeline

hi @Pchelolo: would it be correct for the Editing Team to assume you are curious to know the extent to which VE depends on Etag headers? If so, when would you value hearing an answer from us to this question?

hi @Pchelolo: would it be correct for the Editing Team to assume you are curious to know the extent to which VE depends on Etag headers? If so, when would you value hearing an answer from us to this question?

This would be definitely interesting to know, but we are not blocked on this just yet. We might end up deciding to just keep exactly the same Etag format, then we wouldn't need any input at all. Input is always appreciated, but I will reach out when it's required.

A few services using RESTBase might depend on this ETag format, but I do not quite know of any hard dependencies. We should evaluate whether adopting the same format of ETag is wise (TimeUUID might be quite expensive to generate) and either adopt it, or come up with a new format.

VisualEditor has some code to detect if the etag doesn't match that format, and re-load the page using a different API, which we added when working on issues with etags being mangled between the browser and RESTBase (T233320).

It's not clear to me what this task is about. But let us know if that format changes, because that workaround is still needed as long as we have to use etags to identify entries in Parsoid stash, since etags can apparently disappear or change by themselves.

Change 646812 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[mediawiki/core@master] Make /page/{title}/html emit etags in RESTBase format

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

Change 646812 merged by jenkins-bot:
[mediawiki/core@master] Make /page/{title}/html emit etags in RESTBase format

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