fix(dav): Strip DTSTAMP before etag comparison in webcal refresh

[Olen]

Summary

• Exclude DTSTAMP from etag computation in RefreshWebcalService to prevent false change detection
• DTSTAMP is preserved in stored calendar data (required property per RFC 5545)

Problem

Many iCal providers (Google Calendar, Outlook 365, itslearning) set DTSTAMP to the current UTC time on every feed request per RFC 5545. Since Nextcloud computes the etag as md5(serialized_data) and DTSTAMP changes every time, every event appears modified on every refresh — even if nothing actually changed.

For a Google Calendar subscription with 2,621 events refreshed every ~15 minutes, this generates ~189K false change rows per day in oc_calendarchanges.

Reported at: #51120 (comment)

Approach

Instead of stripping DTSTAMP from the VObject (which would remove a required property from stored data), the fix strips DTSTAMP lines from a copy of the serialized string used only for etag computation:

$sObjectForEtag = preg_replace('/^DTSTAMP:.*\r?\n/m', '', $sObject);
$etag = md5($sObjectForEtag);

The stored calendar data ($sObject) is completely unchanged.

Test plan

• New test testDtstampChangeDoesNotTriggerUpdate verifies a DTSTAMP-only change does not trigger updateCalendarObject
• Updated identicalDataProvider etag computation to match the new DTSTAMP-stripped hashing
• Run RefreshWebcalServiceTest unit tests

Fixes: #51120

🤖 Generated with Claude Code

[tcitworld]

As the DTSTAMP is a required property, we shouldn't remove it from the saved payload, but just do the md5 hash without it.

[Olen]

Thanks for the review @tcitworld — you're absolutely right. DTSTAMP is a required property per RFC 5545 and shouldn't be removed from the stored data.

Apologies for being too quick with the initial approach. I've reworked the fix to be much more minimal: instead of stripping DTSTAMP from the VObject before serialization, it now only strips the DTSTAMP lines from a copy of the serialized string used for the etag/md5 computation. The stored calendar data is completely unchanged — DTSTAMP is preserved.

The diff is now just one line replaced in RefreshWebcalService.php:

-$etag = md5($sObject);
+$sObjectForEtag = preg_replace('/^DTSTAMP:.*\r?\n/m', '', $sObject);
+$etag = md5($sObjectForEtag);

[Olen]

Good point @tcitworld — updated the regex to handle both parameters (DTSTAMP;TZID=...) and RFC 5545 content line folding:

'/^DTSTAMP[;:].*\r?\n([ \t].*\r?\n)*/m'

This matches DTSTAMP starting with either ; (parameters) or : (value), plus any continuation lines starting with a space or tab.

Also added a new test testFoldedDtstampChangeDoesNotTriggerUpdate that uses a DTSTAMP with a long parameter value (X-VOBJ-ORIGINAL-TZID=America/Argentina/Buenos_Aires) exceeding 75 bytes to verify the regex handles folded lines correctly.

[kesselb]

Thanks a lot for your pr 👍

[kesselb]

That seems a bit odd. I think we should rather use the data from $vObject to calculate an etag instead of altering the serialized object with regex.

I'm also seeing the changing dtstamp with my google test account:

Request 1

BEGIN:VEVENT
DTSTART:20250905T163000Z
DTEND:20250905T173000Z
DTSTAMP:20260210T144443Z
UID:1234-1234-1234-1234
CREATED:20250904T204927Z
LAST-MODIFIED:20250904T204927Z
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Testing 3
TRANSP:OPAQUE
END:VEVENT

Request 2 (a few seconds later)

BEGIN:VEVENT
DTSTART:20250905T163000Z
DTEND:20250905T173000Z
DTSTAMP:20260210T144446Z
UID:1234-1234-1234-1234
CREATED:20250904T204927Z
LAST-MODIFIED:20250904T204927Z
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Testing 3
TRANSP:OPAQUE
END:VEVENT

What do you think to calculate the etag from "UID + Last-Modified + Sequence + DTSTART + DTSEND" @tcitworld @SebastianKrupinski?

[SebastianKrupinski]

@kesselb

I think that approach would work... as long as the source updates those fields properly... which is a big IF...

My idea would be to just serialize the object twice... once with the DTSTAMP once with out... But you idea is more efficient

[Olen]

Just let me know if you decide you want to build the etag differently. I will update the PR to match what you think is best. I only noticed because the table was growing huge with updates for some of my calendars.