[wp-trac] [WordPress Trac] #47676: Add support for If-Unmodified-Since header to make a conditional request when updating posts via REST API (for offline and collaborative editing)

[WordPress Trac]

#47676: Add support for If-Unmodified-Since header to make a conditional request
when updating posts via REST API (for offline and collaborative editing)
--------------------------+-----------------------------
 Reporter:  westonruter   |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Editor        |    Version:  4.7
 Severity:  normal        |   Keywords:
  Focuses:  rest-api      |
--------------------------+-----------------------------
 In order to guard against accidentally overwriting someone else's changes
 when updating a post via the REST API, there should be support added for
 [https://tools.ietf.org/html/rfc7232 Conditional Requests]. If a post
 update request includes an [https://developer.mozilla.org/en-
 US/docs/Web/HTTP/Headers/If-Unmodified-Since If-Modified-Since] header and
 the supplied date is ''before'' the post's `post_modified_gmt` then the
 request should fail with a [https://developer.mozilla.org/en-
 US/docs/Web/HTTP/Status/412 412 Precondition Failed] response, with no
 change to the post being made.

 It seems generally useful to include this `If-Unmodified-Since` header
 when making requests to update posts in the editor as additional
 protection on top of post locking.

 Additionally, this header will be important when adding support for
 [https://github.com/WordPress/gutenberg/issues/6322 offline editing], in
 particular when a [https://developers.google.com/web/fundamentals/primers
 /service-workers/ service worker] (see [https://github.com/xwp/pwa-wp PWA
 feature plugin]) is sending queued REST API requests which were made while
 the user was offline (via
 [https://developers.google.com/web/updates/2015/12/background-sync
 background sync]). Since it could be several hours or days between when a
 post was edited and the user goes back online, there needs to be
 protection against overwriting the post on the server if it has been
 modified in the mean time.

 When the service worker uses background sync to re-send the request and it
 fails with a 412 Precondition Failed response, this would then be a signal
 for the service worker to re-submit the changes as an autosave revision
 which could then be shown to the user via some conflict resolution UI the
 next time they access the editor.

 As such, this is also important for the '''collaborative editing''' in a
 future phase.

 See also comments at
 https://github.com/WordPress/gutenberg/issues/6322#issuecomment-410578818

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47676>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform