On our server, we have implemented a means to get dynamic iCalendar feeds for our events. This is handled by first calling a Coldfusion script that renders the iCalendar file, and returns that after setting a content type of "text/calendar; charset=UTF-8". What gets called is something like this: http://www.mysite.com/ical.cfm?calendar_id=1
However, we have noticed this causing issues between things like mobile devices, etc. The iPad will not "subscribe" to this, but rather import the events; which is not good as we want these to update. Other browsers simply prompt to download the ICS file, which again would lead people to import a single file and not really "subscribe" to events (we have also played around with Content-Disposition headers to get the filename fixed to ".ics" instead of downloading as ".cfm").
We then tried using "webcal://" instead of "http://" on the links. That seemed to fix the iPad issues, and Firefox would then ask to open the link in another application (which I guess somebody could choose their calendar app). However, now Chrome will not do anything; we click on the link and it simply does nothing. Webcal is not a standard "protocol", so I can there being issues with it.
Now, I opened Wireshark to inspect a packet delivering a Google iCalendar file (which links up just fine in any browser and the iPad), and there was nothing special about it, aside from some caching headers and custom "X" headers, the only thing to note was the content type was set to exactly what we are delivering.
So, am wondering if anyone has some pointers on getting this to work the same across all the browsers and the iPad/iPhone. Could it be that the fact the link is calling a ".cfm" instead of a ".ics" is throwing off some things? If so, I guess we could implement a re-write rule to solve this...
After experimenting with this some more, not too sure if there is a sure-fire way to get this to work across multiple platforms. It seems that for things like iPhones and iPads, they require a "webcal://" link in order to subscribe via Apple's calendar app. Some browsers are okay with this format, others not so much.
This really would involve creating an interface allowing people to choose the proper download for their device or using the User-Agent from the request on the server side to target the link in the appropriate format for the given device/browser.