Summary
The If-Overwritten-Version header documented in the RERUM API is not being enforced by TinyNode's /overwrite endpoint. Requests succeed even when the version in the header doesn't match the current server version.
Expected Behavior
According to the RERUM API documentation:
Including the 'If-Overwritten-Version' header with the value of the __rerum.isOverwritten property of the record will cause the request to fail if the record has been overwritten since that time.
When a client sends an /overwrite request with an If-Overwritten-Version header that doesn't match the current __rerum.isOverwritten value on the server, the server should return 409 Conflict.
Actual Behavior
The request succeeds with 200 OK and the object is overwritten, even when the If-Overwritten-Version header contains an outdated timestamp.
Steps to Reproduce
- Load an object and note its
__rerum.isOverwritten value (e.g., 2025-11-30T20:31:57.853)
- Update the object via
/overwrite - this changes isOverwritten to a new value (e.g., 2025-11-30T20:33:58.609)
- Send another
/overwrite request with header If-Overwritten-Version: 2025-11-30T20:31:57.853 (the old value)
- Expected: 409 Conflict response
- Actual: 200 OK, object is overwritten
Evidence
Request headers sent (verified in browser DevTools):
if-overwritten-version: 2025-11-30T20:31:57.853
content-type: application/json
Server's current isOverwritten at time of request: 2025-11-30T20:33:58.609
Response: 200 OK (should have been 409 Conflict)
Use Case
This feature is needed to implement optimistic locking for concurrent editing. Without server-side enforcement, two users editing the same object can silently overwrite each other's changes.
Related
Summary
The
If-Overwritten-Versionheader documented in the RERUM API is not being enforced by TinyNode's/overwriteendpoint. Requests succeed even when the version in the header doesn't match the current server version.Expected Behavior
According to the RERUM API documentation:
When a client sends an
/overwriterequest with anIf-Overwritten-Versionheader that doesn't match the current__rerum.isOverwrittenvalue on the server, the server should return 409 Conflict.Actual Behavior
The request succeeds with 200 OK and the object is overwritten, even when the
If-Overwritten-Versionheader contains an outdated timestamp.Steps to Reproduce
__rerum.isOverwrittenvalue (e.g.,2025-11-30T20:31:57.853)/overwrite- this changesisOverwrittento a new value (e.g.,2025-11-30T20:33:58.609)/overwriterequest with headerIf-Overwritten-Version: 2025-11-30T20:31:57.853(the old value)Evidence
Request headers sent (verified in browser DevTools):
Server's current
isOverwrittenat time of request:2025-11-30T20:33:58.609Response: 200 OK (should have been 409 Conflict)
Use Case
This feature is needed to implement optimistic locking for concurrent editing. Without server-side enforcement, two users editing the same object can silently overwrite each other's changes.
Related