My WordPress website runs on a shared Apache webserver. I use a commercial plugin to record client bookings. This plugin registers a custom WordPress feed with add_feed() in plugin init. When requested with its link, the server feed response contains an inline .ics calendar file: the plugin sets a few header lines for 'Content-type: text/calendar; charset=utf-8' and 'Content-Disposition: inline; filename=' . $filename ). It then generates VEvents by looping through its table with bookings. So this feed is not in any way linked to normal posts, etc. Also important to note is that the plugin does not output a last-modified date in the header. This feed works fine for most devices and external sites requesting the web calendar file.
One of my devices (iPhone on iOS 14) could not refresh this calendar subscription. The initial subscription resulted in a valid web calendar on the device, but updates would not come through. Upon examining the headers it became clear that the iPhone was the only device that sent an if-modified-since in its request header when trying to refresh/update the calendar. The web server responded with a 304 Not Modified and did not send the feed / file.
I now have a workaround in .htaccess that eliminates if-modified-since in request headers for .ics files, but this does not solve the root cause.
The issue is that the web server compares the if-modified-since date with another date, possibly the last-modified date that it sends for the original file. As specified, the last-modified is not generated by the plugin, but the server outputs it every time. The plugin author has no idea where that last-modified date for that feed is derived from. They say WordPress does not offer hooks or actions to set/modify the date of a feed, as it is generated dynamically. Testing with a feed from their server: that feed is always delivered, although the last-modified contained in the header of the feed is later than the if-modified-since in the iPhone's request header.
Any suggestions which date comparison my Apache server or WordPress configuration could be performing when returning the 304 response for this WordPress feed? Any ideas on how to solve this?