Feature Request: Configurable field exclusions for ETag calculation in http storage

[balli1187]

Problem

When using the http storage type to sync public ICS calendar feeds, vdirsyncer recalculates the ETag from from content on every sync run. Many public calendar providers (e.g. calovo, but likely others as well) update volatile fields like DTSTAMP, LAST-MODIFIED, and SEQUENCE on every export — even when no events have actually changed.

This causes vdirsyncer to treat the events / entire calendar as modified on every sync run, resulting in (all) events being deleted and re-created in the target storage (e.g. Nextcloud via CalDAV). The sync never reaches a stable state.

Since the file content differs, vdirsyncer detects a change and re-uploads all events, even though no meaningful data changed.

Current workaround

We are experimenting with a preprocessing script that strips volatile fields before vdirsyncer reads the file, and switched from http storage to filesystem storage to allow per-VEVENT UID-based comparison. This seems to be working, but adds significant complexity to the setup.

Proposed solution

Add an optional ignore_fields parameter to the http storage that excludes specified iCalendar fields from the ETag calculation. This would allow users to declare fields that are known to be volatile and irrelevant for change detection.

Example configuration:

[storage my_public_calendar]
type = "http"
url = "https://example.com/calendar.ics"
read_only = true
ignore_fields = ["DTSTAMP", "LAST-MODIFIED", "SEQUENCE"]

Why this makes sense

• DTSTAMP, LAST-MODIFIED, and SEQUENCE are standard iCalendar fields that many providers update automatically on every export, regardless of actual event changes
• These fields carry no meaningful information in the context of read-only public feeds
• The feature would be fully opt-in and backwards compatible — existing configurations are unaffected
• It would eliminate the need for preprocessing workarounds for a common real-world use case
• The problem is not specific to any single provider — any public ICS feed with server-side timestamp updates is affected

Environment

• vdirsyncer 0.20.0
• Target: Nextcloud CalDAV
• Source: Public ICS feeds (calovo.com)

[WhyNotHugo]

pimsync ignores the fields DTSTAMP, LAST-MODIFIED, and SEQUENCE when comparing equality, so this should be a non-issue there.

vdirsyncer is slowly being deprecated in favour of that, so the recommendation is to use pimsync instead.

That said, if someone submits a clean patch here I have no objection to it, but I won't sink time into addressing this.