I understood this to be new Parsoid functionality?

In T104663#1710691, @Krenair wrote:

I understood this to be new Parsoid functionality?

The 'new' stuff is to give the reference wikitext to Parsoid from RESTbase's cache (new in T114548, now in production), rather than from RESTbase's store of saved revisions.

That, along with the ability to stash things (html, data-parsoid, wikitext of a wt2html conversion) in RESTBase.

To clarify, here's how it works. When transforming from wikitext to HTML using the /apge/transform/wikitext/to/html/{title}/{revision} endpoint, you need to supply and extra stash flag in the body:

body:
  wikitext: 'blah blah',
  stash: true

You will get back the HTML, but the response will contain a special ETag header. Next, after the user modifies the HTML and you need to transform that back to wikitext (either for saving or further editing, no difference) using the /page/transform/html/to/wikitext/{title}/{revision} endpoint, you need to include the previously-received ETag header as the If-Match` header:

headers:
  if-match: {etag_from_wt2html}
body:
  html: '<p>blah blah</p>'

That will prompt RESTBase to send the stashed, modified version of wikitext and data-parsoid to Parsoid rather than the original, vanilla ones. Note also that this functionality is available only in RESTBase, not Parsoid.

@Krenair, @Jdforrester-WMF there is currently a limitation in the stashing mechanism that requires you to supply both the title and revision. This implies it will not work for page creation. Is this an edge case we care about?

I think we only need this to deal with already-modified wikitext, but that can be worked around anyway.

Note that passing in a fake revision '0' should work as well. Setting the page name correctly will make sure that page-dependent magic words, relative links etc work correctly in the wt2html conversion.

In T104663#1715065, @Krenair wrote:

I think we only need this to deal with already-modified wikitext, but that can be worked around anyway.

Great! If it pops up as a use case, we can revisit it.

In T104663#1715428, @GWicke wrote:

Note that passing in a fake revision '0' should work as well.

It wouldn't pass the [getBuckerURI() check](https://github.com/wikimedia/restbase/blob/318d7189e42494c1cf9e1a2066e8ed637340707f/mods/parsoid.js#L194), causing key_rev_value to return a 400 on a PUT (which happens during stashing), but that's a minor detail.

It wouldn't pass the getBuckerURI() check, causing key_rev_value to return a 400 on a PUT (which happens during stashing), but that's a minor detail.

Hmm, yeah. Use revision '1' instead ;)

I'm wondering about the scope of this ticket now... We seem to have most of the RESTBase parts in place (except T115165: Add Access-Control-Expose-Headers header in response to allow access to ETag) and AFAIK, VRS does not need to be changed.