-
Notifications
You must be signed in to change notification settings - Fork 147
Description
Environment
- Server version: 7.1.7
- Node.js version: 22.21.1
- npm version: 10.9.4
Description
The ETag sent by the CSS uses a UNIX timestamp to distinguish between different versions of a single resource. The timestamp is in seconds, which causes issues when two modification requests are done within one second. In this case, the client that made the request first receives a 302 Not Modified response for subsequent GET requests, even though the resource contains different data.
I took a look to the code and the behavior is caused by the updateModifiedDate function which removes milliseconds from the metadata.
CommunitySolidServer/src/util/ResourceUtil.ts
Lines 34 to 39 in 5ff9424
| export function updateModifiedDate(metadata: RepresentationMetadata, date = new Date()): void { | |
| // Milliseconds get lost in some serializations, potentially causing mismatches | |
| const lastModified = new Date(date); | |
| lastModified.setMilliseconds(0); | |
| metadata.set(DC.terms.modified, toLiteral(lastModified.toISOString(), XSD.terms.dateTime)); | |
| } |
I think that the comment about issues with milliseconds refers to the fact that the HTTP headers If-Modified-Since and If-Unmodified-Since do not include milliseconds. The values of these two headers are used to check BasicConditions.
CommunitySolidServer/src/storage/conditions/BasicConditions.ts
Lines 56 to 65 in 5ff9424
| const modified = metadata.get(DC.terms.modified); | |
| if (modified) { | |
| const modifiedDate = new Date(modified.value); | |
| if (this.modifiedSince && modifiedDate < this.modifiedSince) { | |
| return false; | |
| } | |
| if (this.unmodifiedSince && modifiedDate > this.unmodifiedSince) { | |
| return false; | |
| } | |
| } |
I have not found any other place where the presence of milliseconds in the dcterms:modified value could cause problems.