(In reply to Sébastien Villemot from comment #4)
> What I still don't get however is why a transfer of 26Mb is needed for a
> 300kb ICS file.

I forgot to comment on that. That happens on the server side. There was a
recent change in libical that causes it to include the entire history of a time
zone in each item. For example, most data logged for the first item in your log
file is just the VTIMEZONE:

<getetag>"c6dd224d03da4ef8a74750b9dc73d40c"</getetag>
<C:calendar-data>BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:/freeassociation.sourceforge.net/Tzfile/America/Montreal
X-LIC-LOCATION:America/Montreal
BEGIN:STANDARD
TZNAME:EST
DTSTART:19691026T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
X-RADICALE-NAME:/freeassociation.sourceforge.net/Tzfile/America/Montreal
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EDT
DTSTART:19700426T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
X-RADICALE-NAME:/freeassociation.sourceforge.net/Tzfile/America/Montreal
END:DAYLIGHT 
...

Worse, the *same* item also contains other VTIMEZONEs. I don't know why that
happens. Radicale should only send the VTIMEZONE definitions actually
referenced in an item. Check your .ics file - perhaps a client stored the item
as it later gets send out by the server? But then the .ics file itself should
already be much larger.

For libical, see 
http://sourceforge.net/p/freeassociation/bugs/95/
http://lists.infradead.org/pipermail/libical-devel/2014-October/000627.html