I believe your server’s replies include an Etag, which the client then uses to make the request. If you remove this header from the answer, then the client will not set the If-None-Match header when making a request, and the server will send the correct reply to the client. So, adding the following lines in .htaccess should solve the problem:
# Disable ETags
<IfModule mod_headers.c>
Header unset ETag
</IfModule>
FileETag None
Correction
The plugin replies include a last-modified header, as in
last-modified: Wed, 21 Apr 2021 18:22:20 GMT
which is a good thing by itself, except when it’s not. For some unknown to me reason (bug?) the date in this header stays always the same, regardless of what has changed in the calendar since. Some mobile clients include in their request the If-Modified-Since header, as in
If-Modified-Since:Thu, 27 May 2021 13:23:28 GMT
and if this date is more recent than the last-modified date, the server sends a 304, otherwise a 200. Since the last-modified date is stuck in the past, the server always sends a 304. The least intrusive thing to do is ask the server to ignore the If-Modified-Since header, which can be easily achieved with the RequestHeader directive like this:
# Disable ETags from replies and If-Modified-Since from requests
<IfModule mod_headers.c>
Header unset ETag
RequestHeader unset If-Modified-Since
</IfModule>
FileETag None
This has the extra cost of downloading the calendar on every request, not taking into account wether anything has actually changed, but in my case this was an acceptable cost.