[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#781168: marked as done (Workarounds for Google being evil with .ics feeds)

Your message dated Tue, 02 May 2023 23:28:22 +0200
with message-id <3696725.PjJxKfDQY6@tuxin>
and subject line Re: Bug#781168: Workarounds for Google being evil with .ics feeds
has caused the Debian Bug report #781168,
regarding Workarounds for Google being evil with .ics feeds
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
781168: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781168
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: akonadi-server
Version: 1.13.0-2
Severity: normal

Hello,

I have as a calendar source an .ics served by Google, with an address
like this: https://www.google.com/calendar/ical/person%40gmail.com/private-12341234123412341234123412341234/basic.ics

It looks like Google is being evil by breaking all the assumptions that
allow an efficient update of that data feed. Not only they did not
implement neither If-Modified-Since nor a sensible modification date for
their ical server:

  Current date/time: Wed, 25 Mar 2015 14:34:24 +0000

  Headers for a HEAD request on the ics url:

     Content-Type: text/calendar; charset=UTF-8
     X-Content-Type-Options: nosniff
     Pragma: no-cache
     Content-Length: 312906
     Alternate-Protocol: 443:quic,p=0.5
     Server: GSE
     Cache-Control: no-cache, no-store, max-age=0, must-revalidate
     Expires: Fri, 01 Jan 1990 00:00:00 GMT
     Date: Wed, 25 Mar 2015 14:34:24 GMT
     X-XSS-Protection: 1; mode=block
     X-Frame-Options: SAMEORIGIN

But also the content is significantly different. This is the list of
what I have observed Gmail doing to an unchanged ical feed:

 - DTSTAMP of each element is always now
 - VTIMEZONE entries appear in random order
 - ORGANIZER CN entries randomly change between full name and plus.google.com
   user ID
 - ATTENDEE entries randomly change between having a CN or not having it
 - TRIGGER entries change spontaneously
 - CREATED entries change spontaneously

This causes akonadi to download and reprocess the entire ical feed every
single time. In this case we are talking about 300Kb, which is a lot of
ical data, and I end up with akonadi and the database working more often
than not, a hot an noisy laptop, and an unhealthy amount of anger.

I am now working on a smart diff between ical files that should be able
to tell when two .ics files mangled that way are still actually the
same. I'll try to keep you posted.


Thank you,

Enrico

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages akonadi-server depends on:
ii  akonadi-backend-postgresql      1.13.0-2
ii  libakonadiprotocolinternals1    1.13.0-2
ii  libboost-program-options1.55.0  1.55.0+dfsg-3
ii  libc6                           2.19-15
ii  libgcc1                         1:4.9.2-10
ii  libqt4-dbus                     4:4.8.6+git64-g5dc8b2b+dfsg-3
ii  libqt4-network                  4:4.8.6+git64-g5dc8b2b+dfsg-3
ii  libqt4-sql                      4:4.8.6+git64-g5dc8b2b+dfsg-3
ii  libqt4-xml                      4:4.8.6+git64-g5dc8b2b+dfsg-3
ii  libqtcore4                      4:4.8.6+git64-g5dc8b2b+dfsg-3
ii  libqtgui4                       4:4.8.6+git64-g5dc8b2b+dfsg-3
ii  libstdc++6                      4.9.2-10

akonadi-server recommends no packages.

Versions of packages akonadi-server suggests:
pn  akonadi-backend-mysql       <none>
ii  akonadi-backend-postgresql  1.13.0-2
pn  akonadi-backend-sqlite      <none>

-- no debconf information

--- End Message ---
--- Begin Message --- 
Version: 4:20.08.3-3

Hey,

nowadays there are  explicit Google resources that handles calendars directly 
through the Google APIs. That should handle the special way Google treat 
calendar events.

Regards,

hefee

--


On Mittwoch, 25. März 2015 16:24:40 CEST Enrico Zini wrote:
> Package: akonadi-server
> Version: 1.13.0-2
> Severity: normal
> 
> Hello,
> 
> I have as a calendar source an .ics served by Google, with an address
> like this:
> https://www.google.com/calendar/ical/person%40gmail.com/private-12341234123
> 412341234123412341234/basic.ics
> 
> It looks like Google is being evil by breaking all the assumptions that
> allow an efficient update of that data feed. Not only they did not
> implement neither If-Modified-Since nor a sensible modification date for
> their ical server:
> 
>   Current date/time: Wed, 25 Mar 2015 14:34:24 +0000
> 
>   Headers for a HEAD request on the ics url:
> 
>      Content-Type: text/calendar; charset=UTF-8
>      X-Content-Type-Options: nosniff
>      Pragma: no-cache
>      Content-Length: 312906
>      Alternate-Protocol: 443:quic,p=0.5
>      Server: GSE
>      Cache-Control: no-cache, no-store, max-age=0, must-revalidate
>      Expires: Fri, 01 Jan 1990 00:00:00 GMT
>      Date: Wed, 25 Mar 2015 14:34:24 GMT
>      X-XSS-Protection: 1; mode=block
>      X-Frame-Options: SAMEORIGIN
> 
> But also the content is significantly different. This is the list of
> what I have observed Gmail doing to an unchanged ical feed:
> 
>  - DTSTAMP of each element is always now
>  - VTIMEZONE entries appear in random order
>  - ORGANIZER CN entries randomly change between full name and
> plus.google.com user ID
>  - ATTENDEE entries randomly change between having a CN or not having it
>  - TRIGGER entries change spontaneously
>  - CREATED entries change spontaneously
> 
> This causes akonadi to download and reprocess the entire ical feed every
> single time. In this case we are talking about 300Kb, which is a lot of
> ical data, and I end up with akonadi and the database working more often
> than not, a hot an noisy laptop, and an unhealthy amount of anger.
> 
> I am now working on a smart diff between ical files that should be able
> to tell when two .ics files mangled that way are still actually the
> same. I'll try to keep you posted.
> 
> 
> Thank you,
> 
> Enrico
> 
> -- System Information:
> Debian Release: 8.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.19.0-trunk-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages akonadi-server depends on:
> ii  akonadi-backend-postgresql      1.13.0-2
> ii  libakonadiprotocolinternals1    1.13.0-2
> ii  libboost-program-options1.55.0  1.55.0+dfsg-3
> ii  libc6                           2.19-15
> ii  libgcc1                         1:4.9.2-10
> ii  libqt4-dbus                     4:4.8.6+git64-g5dc8b2b+dfsg-3
> ii  libqt4-network                  4:4.8.6+git64-g5dc8b2b+dfsg-3
> ii  libqt4-sql                      4:4.8.6+git64-g5dc8b2b+dfsg-3
> ii  libqt4-xml                      4:4.8.6+git64-g5dc8b2b+dfsg-3
> ii  libqtcore4                      4:4.8.6+git64-g5dc8b2b+dfsg-3
> ii  libqtgui4                       4:4.8.6+git64-g5dc8b2b+dfsg-3
> ii  libstdc++6                      4.9.2-10
> 
> akonadi-server recommends no packages.
> 
> Versions of packages akonadi-server suggests:
> pn  akonadi-backend-mysql       <none>
> ii  akonadi-backend-postgresql  1.13.0-2
> pn  akonadi-backend-sqlite      <none>
> 
> -- no debconf information

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---
Reply to: