Add support for If-Unmodified-Since header to make a conditional request when updating posts via REST API (for offline and collaborative editing)

[westonruter]

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 ​Conditional Requests. If a post update request includes an ​If-Modified-Since header and the supplied date is before the post's post_modified_gmt then the request should fail with a ​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 ​offline editing, in particular when a ​service worker (see ​PWA feature plugin) is sending queued REST API requests which were made while the user was offline (via ​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

[westonruter]

​https://github.com/westonruter/wordpress-develop/pull/3

[TimothyBlynJacobs]

Why If-Unmodified-Since instead of using ETag's? An ETag could be built by serializing the item response. That would handle updates to the entity that don't trigger post_modified like metadata, terms, and any other custom fields.

Or is the fact that post_modified would only track changes to the post resource a benefit?

One downside to an ETag is it'd be more intensive to calculate. I suppose if we wanted to get similar benefits, we could force a post_modified update whenever a post entity is updated through the posts controller.

---

If the If-Unmodified-Since is used I think we should definitely send Last-Modified as a header, and ideally support If-Modified-Since as well. Last-Modified can also be sent as a ​targetHint so it is accessible in the collection route.

[westonruter]

Replying to TimothyBlynJacobs:

Why If-Unmodified-Since instead of using ETag's? An ETag could be built by serializing the item response.

Good question. I didn't think about that. One issue with using ETag generated from serializing the response is that it would require always querying data for all fields, even if they are not requested by the user. For example, if someone had obtained the entity originally via /wp-json/wp/v2/posts/2553?_fields=id,title,link and then they modify the title and PUT back the modified post, then the ETag would not have been generated to include the content. Or perhaps this doesn't matter because you only requested the title in the first place?

That would handle updates to the entity that don't trigger post_modified like metadata, terms, and any other custom fields.
I suppose if we wanted to get similar benefits, we could force a post_modified update whenever a post entity is updated through the posts controller.

That is a very good point. For custom fields, the only thing to protect against that would be to store some additional last_modified in postmeta and bump it whenever postmeta is changed or term associations are changed, such as via the posts controller. But that's not ideal.

Or is the fact that post_modified would only track changes to the post resource a benefit?

The post_modified would probably be an 80% solution.

If the If-Unmodified-Since is used I think we should definitely send Last-Modified as a header, and ideally support If-Modified-Since as well. Last-Modified can also be sent as a ​targetHint so it is accessible in the collection route.

Another great point. Yes, sending the Last-Modified header as derived from post_modified_gmt is something I missed. A client should not be trying to convert the post_modified_gmt into a value to for the If-Unmodified-Since header.

One downside to an ETag is it'd be more intensive to calculate.

I see it being more intensive in two ways:

1. The get_item method would need to compute the ETag from serializing the response data.
2. The update_item method would need to call get_item if the request has an If-Match header, and then compare the get_item method's response ETag with the PUT request's If-Match header to see if there is a match.

In other words:

src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php

@@ -477 +477 @@
                         $response->link_header( 'alternate', get_permalink( $post->ID ), array( 'type' => 'text/html' ) );
                 }
 
+                $response->set_headers(
+                        array(
+                                'ETag' => sprintf( '"%s"', md5( serialize( $response->get_data() ) ) ),
+                        )
+                );
+
                 return $response;
         }
 
@@ -685 +691 @@
                         return $valid_check;
                 }
 
+                // Handle conditional request.
+                if ( $request->get_header( 'If-Match' ) ) {
+                        $get_request = clone $request;
+                        $get_request->set_method( 'GET' );
+                        $get_request->set_body( null );
+                        $etag = md5( serialize( $this->get_item( $get_request )->get_data() ) );
+                        if ( $etag !== trim( $request->get_header( 'If-Match' ), '"' ) ) {
+                                return new WP_Error( 'rest_precondition_failed', __( 'Post has been changed on server. Please resolve conflicts and try again' ), array( 'status' => 412 ) );
+                        }
+                }
+
                 $post = $this->prepare_item_for_database( $request );
 
                 if ( is_wp_error( $post ) ) {