На нашем сервере мы внедрили средство для получения динамических каналов iCalendar для наших событий. Для этого сначала вызывается сценарий Coldfusion, который отображает файл iCalendar и возвращает его после установки типа содержимого «текст/календарь; charset=UTF-8». То, что вызывается, выглядит примерно так: http://www.mysite.com/ical.cfm?calendar_id=1
Однако мы заметили, что это вызывает проблемы между такими вещами, как мобильные устройства и т. д. iPad не будет «подписываться» на это, а скорее импортирует события; что нехорошо, так как мы хотим, чтобы они обновлялись. Другие браузеры просто предлагают загрузить файл ICS, что опять же приводит к тому, что люди импортируют один файл, а не «подписываются» на события (мы также поиграли с заголовками Content-Disposition, чтобы вместо этого имя файла было исправлено на «.ics» загрузки как ".cfm").
Затем мы попытались использовать «webcal://» вместо «http://» в ссылках. Это, казалось, решило проблемы с iPad, и Firefox затем попросил открыть ссылку в другом приложении (которое, я думаю, кто-то мог выбрать в своем приложении календаря). Однако теперь Chrome ничего не сделает; мы нажимаем на ссылку, и она просто ничего не делает. Webcal не является стандартным «протоколом», поэтому у меня могут возникнуть проблемы с ним.
Теперь я открыл Wireshark, чтобы проверить пакет, доставляющий файл Google iCalendar (который прекрасно линкуется в любом браузере и на iPad), и в нем не было ничего особенного, кроме нескольких заголовков кэширования и настраиваемых заголовков «X». Следует отметить, что тип контента был установлен именно на то, что мы доставляем.
Итак, мне интересно, есть ли у кого-нибудь указания, как заставить это работать одинаково во всех браузерах и на iPad/iPhone. Может ли быть так, что тот факт, что ссылка вызывает «.cfm» вместо «.ics», отбрасывает некоторые вещи? Если это так, я думаю, мы могли бы реализовать правило перезаписи, чтобы решить эту проблему...
