Page MenuHomePhabricator

Wikitext surface needs an etag to use RESTBase
Closed, InvalidPublic8 Story Points

Description

If we go straight to the WT surface using veaction=editsource, we don't bother loading the HTML document form RESTBase, which means we don't get an etag. Without an etag we can't ask for html->wikitext snippet conversions via the RB/VirtualRB.

Related Objects

StatusAssignedTask
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedEsanders
OpenNone
OpenNone
ResolvedJules78120
OpenNone
ResolvedDannyH
OpenNone
OpenEsanders
OpenNone
OpenEsanders
ResolvedJdforrester-WMF
InvalidNone

Event Timeline

Esanders created this task.Aug 12 2016, 8:12 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 12 2016, 8:12 PM
Jdforrester-WMF set the point value for this task to 8.Aug 17 2016, 8:56 PM
Krenair edited subscribers, added: AlexMonk-WMF; removed: Krenair.Aug 24 2016, 6:18 PM

I think maybe we should ask RESTBase for a GET call we can do to /page/wikitext/{title}//page/wikitext/{title}/{revision} that'd get the wikitext from MW (or it's own cache) and return it with an ETag?

Is this for the Service's team sanity/good logging, or does it break the editor in some way that I haven't noticed?

I'm not quite sure, but I think it might mean dirty diffs if you veaction=editsource, make changes, then switch to VE and save?

I'm not quite sure, but I think it might mean dirty diffs if you veaction=editsource, make changes, then switch to VE and save?

Not in my (relatively brief) testing.

Without an etag we can't ask for html->wikitext snippet conversions via the RB/VirtualRB.

This doesn't seem to be quite right. We send a null etag to MultiHttpClient as the if-match header, it gets converted to an empty string by a trim() call in getCurlHandle, and it still works...

Pchelolo added a subscriber: Pchelolo.

I'm not quite sure, but I think it might mean dirty diffs if you veaction=editsource, make changes, then switch to VE and save?

The ETag is used within RESTBase to locate the exact version of data-parsoid corresponding to the original HTML you've based your edit on. In RESTBase we require an ETag to be present either in If-Match header, or inlined in HTML with meta property=mw:TimeUuid element (less desirable). If we didn't require an ETag, if the page was rerendered (for example due to a template change and Change-Prop change) in the timeframe between the original HTML was requested and the transform request was submitted, the data-parsoid versions could mismatch leading to dirty diffs and all the other problems. So, you wouldn't see the issues all the time, but they would manifest sometimes.

I don't understand the problem though - if you are in the WT editor, why would you need to call html->wikitext transform? And if you're switching to HTML editor - don't you load the original HTML? Could you please tell more about your use-case?

Yesh - if you are using wikitext mode only we fetch wikitext directly from the PHP API, because there is no RESTBase API for getting wikitext. If we switch to VE, we use the same API calls as we currently use for switching from source mode.

Jdforrester-WMF closed this task as Invalid.Dec 12 2016, 11:04 PM

I'm provisionally closing this as Invalid as it doesn't seem to be an issue. We can re-open if it turns out I'm wrong.