Currently, RESTBase injects a meta mw:TimeUUID tag in the body of Parsoid HTML it returns, to provide a fall-back for clients not sending the If-Match header. But, this is a hack that caused some unexpected bugs (cf T113163: Cannot save existing pages using IE11). The best solution is to abandon it and switch to the proper solution of VE setting the If-Match header.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Duplicate | None | T113728 VE should send If-Match header to the VRS to send on to RESTbase | |||
| Resolved | • mobrovac | T115165 Add Access-Control-Expose-Headers header in response to allow access to ETag |
Event Timeline
Comment Actions
Will this require changes to the VRS? One of the benefits of T112553: Integrate the Virtual Rest Service (VRS) into core, and make it generally available (from RequestContext?) might be that we can centralize this code so that we only have to fix issues like this in a single place.
Comment Actions
Only if VRS can maintain state across an edit's lifecycle, which I doubt it can, and which I don't think it should. So, clients aren't absolved from having to do it on their end.
It does seem simpler to me (in terms of client expectations) to leave the meta tag in the <head>. That way, clients that don't need to know or care about it can leave it alone and the only expectation is to not mess with it.
Comment Actions
It does seem simpler to me (in terms of client expectations) to leave the meta tag in the <head>. That way, clients that don't need to know or care about it can leave it alone and the only expectation is to not mess with it.
Clients already remember the version they worked with; remembering the ETag & sending it back isn't much harder, really. We could even consider getting rid of the {/revision} part of the entry point, as the same information is already contained in the ETag header. This would keep the number of explicit parameters to supply constant.
Comment Actions
Yup, it is not very difficult. Just simpler since the meta-tag is in the <head> already (unless you are saying the info is coming in the headers and not the HTML).
Anyway, as long as you fail fast, all clients will be forced to comply.
Comment Actions
Anyway, as long as you fail fast, all clients will be forced to comply.
Yeah, but breaking things without warning might not be the best way to achieve consensus on API changes ;)
One thing that's nice about If-Match is that it's very general. It'll work for any kind of content, including section edits, metadata edits, or data-mw edits.
Comment Actions
Right, I didn't suggest that .. but, once all known existing clients have migrated over, you fail fast.
Comment Actions
And, as they say .. I don't have a horse in this race .. so, I'll let you guys figure it out. :)
Comment Actions
I think we send an If-Match header containing the provided ETag now, yes. I don't know which part of the code sets mw:TimeUUID though. @Catrope?
Comment Actions
Oh... Actually, that probably only works when you access restbase directly, not in any other configuration.
Comment Actions
Thank you, @Krenair.
Contrary to what was stated in the original task description, VE shouldn't need to worry about mw:TimeUuid, as this is something RESTBase injects into the Parsoid HTML it returns. On the way back, it is then used as a fall-back when clients don't send if-match.
This is a fairly gross hack, and we'll stop injecting that meta tag once we know that all clients are indeed sending if-match.