Календарь Google не может импортировать мой файл ical

Предположим, у меня есть какой-то контроллер «Контроллер» и общедоступный метод:

public ActionResult GetICal(int? param1, int? param2)
{
    string cal = "";
    //some logic goes here
    return File(Encoding.UTF8.GetBytes(cal), "text/calendar", "calendar.ics");
}

Затем я пытаюсь экспортировать его в Календарь Google по URL-адресу: https://my.site.com/controller/getIcal?param1=0¶m2=1

А потом ничего не происходит. Однажды я получил сообщение типа «Не удается получить URL-адрес» (или что-то в этом роде).

Я не знаю, что я делаю неправильно. Этот URL на 100% доступен без авторизации. И если я добавляю этот календарь через файл, все идет нормально (поэтому календарь имеет правильный формат).


google-calendar-api c# asp.net asp.net-mvc icalendar
person Konstantin Vasilev    schedule 04.11.2013    source источник
comment
почему вы должны ? по вашим параметрам int   -  person 06needhamt    schedule 04.11.2013
comment
Это просто образец. На самом деле я передаю здесь даты начала/окончания и некоторую информацию для выбора необходимых событий.   -  person Konstantin Vasilev    schedule 04.11.2013

Ответы (2)


arrow_upward
1
arrow_downward

У меня сейчас та же проблема - что мне пришлось изменить, и в чем проблема, как я ее вижу, это параметры в моем URL-адресе. С любыми параметрами это всегда заканчивается сообщением об ошибке «Не удается получить URL».

Но когда я использовал сокращение URL-адресов Google и добавил календарь в качестве этого сокращенного URL-адреса, например http://goo.gl/XXXXX Сработало с первого раза.

person ppetak    schedule 24.01.2014

arrow_upward
1
arrow_downward

Какой тип SSL-сертификата у вашего сервера? Самоподписанный? У нас была аналогичная проблема:

  1. когда мы использовали обычный «http», фид iCal импортировался правильно
  2. когда мы использовали «https» с самозаверяющим сертификатом, Календарь Google не импортировал ленту, но с сервисом goo.gl, как упоминалось ppetak, все было в порядке.
  3. когда мы использовали «https» с сертификатом класса 2, проверенным GoDaddy.com, ситуация была такой же, как и в 2)
  4. когда мы использовали «https» с сертификатом класса 3, проверенным VeriSign, все работает правильно
person plymo    schedule 30.01.2014
comment
Да, мы используем самозаверяющий сертификат. Теперь это имеет смысл. - person Konstantin Vasilev; 03.02.2014