735458 - Behavior of X-If-Unmodified-Since for PUT requests against /storage/collection/id

Status: VERIFIED WONTFIX

(Cloud Services Graveyard :: Server: Sync, defect)

Description

[Ryan Kelly [:rfkelly]]

(We just had this discussion offline, sans rnewman, but I wanted to put it in a bug for posterity)

The Sync2.0 spec currently has the following to say about X-If-Unmodified-Since with PUT /storage/collection/id::

    PUT https://<endpoint-url>/storage/<collection>/<id>

        This request may include the X-If-Unmodified-Since header to avoid overwriting
        the data if it has been changed since the client fetched it. Successful requests
        will receive a 204 No Content response, with the X-Timestamp header giving the
        new modification time of the object.

        Possible HTTP error responses:

            412 Precondition Failed: the object has been modified since the timestamp in
                                     the X-If-Unmodified-Since header.


In other words, it checks the modification time of the individual record being operated on, *not* the modification time of the collection as a whole.  This is in line with the semantics of If-Unmodified-Since, which always applies to the target resource.

However, it seems this is not what we actually want - instead we want it to give a 412 response if *anything* in the collection has been changed, not just the target resource itself.  This protects the client against writing data that might conflict with something else in the collection.  The new text will say:

    PUT https://<endpoint-url>/storage/<collection>/<id>

        This request may include the X-If-Unmodified-Since header to avoid overwriting
        the data if the collection has been changed since the client fetched it.
        Successful requests will receive a 204 No Content response, with the X-Timestamp
        header giving the new modification time of the object.

        Possible HTTP error responses:

            412 Precondition Failed: the containing collection has been modified since
                                     the timestamp in the X-If-Unmodified-Since header.


Is this accurate?  And are there any objections to this deviation from RESTfu...err...from the standard HTTP semantics?

Comment 1

[Richard Newman [:rnewman]]

My initial opinion is that POST should check the collection timestamp, and PUT should check the record timestamp.

Offhand I know of no instance in which the client uses PUT but would care if other elements of the collection are modified.

Comment 2

[Richard Newman [:rnewman]]

Making summary more searchable.

Comment 3

[Gregory Szorc [:gps]]

Making summary more English.

Comment 4

[Richard Newman [:rnewman]]

(In reply to Gregory Szorc [:gps] from comment #3)
> Making summary more English.

itym "less English" -- more Merkin.

Comment 5

[Ryan Kelly [:rfkelly]]

All trololol aside, I'm going to side with rnewman on this one unless someone chimes in with a compelling use-case to the contrary.  X-If-Unmodified-Since should always scope to the target resource of the request, not its container.

Comment 6

[Ryan Kelly [:rfkelly]]

After discussions offline, we're going to keep the current semantics where If-Unmodified-Since relates only to the target resource.  This is implemented in the current codebase so I'm closing this bug.

Note that it could be implemented much *better* than it is currently, and I've opened Bug 739831 to track that.

Comment 7

[James Bonacci [:jbonacci]]

For completeness, marking as Verified.

Comment 8

[Richard Newman [:rnewman]]

To document the current state of the world: 1.1 *does* use the collection timestamp for PUT.

"If the collection to be acted on has been modified since the provided timestamp, the request will fail with an HTTP 412 Precondition Failed status."

This misunderstanding caused Bug 747065 :D