Safari 11.0.3 kann iCal-Datei nicht mehr laden

**allmächt!** · 31.01.2018, 11:40

Guten Tag,

bei CONTAO 3.5.33 kann die iCal-datei nicht mehr geladen werden:

Bildschirmfoto 2018-01-31 um 11.32.06.png

Mit Firefox und Chrome tut es einwandfrei.

Viele Grüße aus Mittelfranken-Süd :-)

**Stefko** · 31.01.2018, 11:50

Moin,

hättest Du mal einen entsprechenden Link?
Danke.

**allmächt!** · 31.01.2018, 11:55

Guten Tag Stefko,

ja klar:

hier: https://spalter-imker.de/kalender.html
und hier: https://www.gartenbauverein-spalt.de/kalender.html

aber hier: http://heimatverein-spalter-land.de/Termine.html tut es merkwürdigerweise.

Viele Grüße

**Stefko** · 31.01.2018, 12:06

hmm, stimmt, kann ich bestätigen ...
Was mir auf Anhieb auffällt, die ersten beiden Seiten sind verschlüsselt, die Seite auf der es funktioniert nutzt http. Würde in der Richtung mal nachforschen ...

**allmächt!** · 31.01.2018, 12:23

Hallo Stefko,
danke für deine schnelle Reaktion.
Das Problem scheint aber bei Safari in Verbindung mit https zu liegen, denn Firefox, Opera und Chrome laden die iCal-Datei einwandfrei.
Ich weiß leider nicht, wie und wo ich da suchen soll :-(
Viele Grüße

P.S. Hier steht etwas zu diesem Problem: https://discussions.apple.com/thread/7612610

**tab** · 31.01.2018, 12:27

Möglicherweise hamdelt es sich um ein Problem mit einem Apache-Server mit vorgeschaltetem nginx Proxy. Da kann es bei schlecht/falsch konfiguriertem nginx z.B. passieren, dass der Apache Dateien per HTTP/2 ausliefert und das auch so im Header angibt - nginx dann allerdings die Datei per HTTP/1.1 ausliefert, aber die entsprechende Headerzeile vom Apache übernimmt. Das passt dann nicht mehr zusammen und es kommt mit Safari zu so einem Fehler. Das Web ist voll mit der Fehlermeldung, einfach mal Google anwerfen.

Edit: Dazu passt, dass bei den nicht funktionerenden Seiten nginx als Server angegeben ist, bei der funktionerenden dagegen Apache

**allmächt!** · 31.01.2018, 12:37

ist ist so, dass die beiden Seiten, bei denen es nicht klappt, bei WebGo liegen, die funktionierende bei Hetzner.
Das weist wohl eher in die Richtung, dass der Fehler etwas mit der Webserver-Konfiguration und Safari 11 zu tun hat.
Grüße

**allmächt!** · 31.01.2018, 12:39

Hallo tab,
danke, ich werde mal Kontakt mit den WebGo-ern aufnehmen.
Schönen Tag euch allen!

**allmächt!** · 01.02.2018, 08:57

Guten Morgen,

was ich nicht ganz verstehe:
warum werden, wenn es am falschen Header liegt, nicht alle Seiten mit dem falschen Header ausgeliefert, sondern nur die zu ladende iCal-Datei?
Ein PDF kann anstandslos geladen werden.

Ich habe mit den WebGo-ern Kontakt aufgenommen. Mal sehen, was die sagen werden.

Viele Grüße

**allmächt!** · 01.02.2018, 15:54

Habe die Ehre,

es liegt an den https Einstellungen von WebGo. Wenn ich die https-Umleitung ausschalte, kann ich die iCal-Datei auch mit Safari 11.0.3 problemlos laden.

Grüße

**allmächt!** · 04.02.2018, 15:02

Ich habe gestern nochmals einiges durchprobiert und bin zu Folgenden Ergebnissen gekommen:

a) Das Phänomen betrifft nur (meine?) Macs (aber davon 4 Stück) mit macOS X 10.13.3 und Safari 11.0.3
b) Das Phänomen betrifft das iPhone 5 meiner Frau und mein iPhone SE, jeweils mit iOS 11.2.2 und Safari
c) Das Phänomen betrifft mein iPad 4 mit iOS 10.3.3 und Safari

Ich beschreibe nochamals den Fehler den man bei diesen drei Webseiten überprüfen kann:

a) Gartenbauverein (im Folgenden GBV bezeichnet): https://www.gartenbauverein-spalt.de/kalender.html
b) Imkerverein (im Folgenden IV bezeichnet): https://spalter-imker.de/kalender.html
c) Heimatverein (im Folgenden HV bezeichnet): http://heimatverein-spalter-land.de/Termine.html

GBV liegt bei WebGo, IV liegt bei WebGo, HV liegt bei Hetzner.
Alle drei verwenden Contao 3.5.33 mit dem gleichen Modul calendar_ical zur Erzeugung der .ics Datei

Es dreht sich immer um das Herunterladen der Kalenderdatei im .ics-Format.

1. Mit macOS X
a) Bei den Seiten GBV und IV kommt, wenn ich MIT SAFARI 11.0.3 die .ics-Datei laden will (auf allen meinen Macs), dieses Fenster: (Anhang Bildschirmfoto)
b) Mit Safari 11.0.3 und HV kann ich die Datei normal laden und in den Kalender einpflegen.

2. Mit iOS 10.33 und 11.2.5
a) Wenn ich bei GBV und IV die iCal-Datei laden will, friert das Fenster ein.
b) Mit Safari kann ich bei HV die Datei normal laden und in den Kalender einpflegen: Nach dem Laden wird dieses Fenster angezeigt: (Anhang IMG_6177)

3. Der Fehler tritt unter
a) macOX X nur bei Safari auf. Mit Chrome, FF oder Opera wird die Kalender-Datei problemlos geladen.
b) iOS sowohl bei Safari als auch unter FF, allerdings wird hier keine Fehlermeldung angezeigt.

4. Wenn ich jedoch bei WebGo für GBV und IV das HTTPS ausschalte, werden die Dateien auch mit Safari problemlos geladen.
Mithin ist das HTTPS-Verfahren von WebGo zumindest mit beteiligt. Aber wer nun der ”Schuldige“ ist, habe ich nicht herausbekommen.

5. Im Netz habe ich zu diesem Problem dieses gefunden:

a) Artikel 1: (help.poralix….)
b) Aussagekräftiger erscheint mir Artikel 2 (blog.christ…). Wenn man diesem Glauben schenken darf, ist Safari der einzige Browser, der sich an einen Standard RFC 7230 hält und deshalb scheitert. Ich habe die Stelle im PDF markiert. Wenn Artikel 2 recht hat, dann müsste der HTTP-Header der .ics Datei fehlerhaft sein.

6. Gleiches Verhalten habe ich bei dem Modul calendar_ical unter CONTAO 4 festgestellt.

7. WebGo kann das nicht testen, da sie keinen einzigen Mac haben (schluchts...)

8. Bei Hetzner kann ich kein HTTPS einschalten, dazu müsste ich einen ganzen Server mieten. :-(

Viele Grüße

P.S. Kann vielleicht jemand bei einem anderen Provider mit HTTPS diese Erweiterung testen?

**tab** · 04.02.2018, 15:19

Die werden doch bei WebGo wenigstens ein iPhone haben zum Testen? iPhone mit Safari reicht ja schon um den Fehler zu reproduzieren. Und dann müssen sie halt ihre Apache und nginx Einstellungen kontrollieren. Deine Quellen zeigen ja einige mögliche Ursachen auf. Das sollte jetzt ja mit all den Informationen keine unlösbare Aufgabe sein. Poste das vielleicht mal ins WebGo Unterforum, da liest zumindestens auch gelegentlich mal jemand von WebGo mit.

Auf HTTPS zu verzichten kann ja auch keine dauerhafte Lösung für dich sein.

**Spooky** · 05.02.2018, 14:30

Welche Extension in welcher Version benutzt du nun eigentlich genau?

**allmächt!** · 05.02.2018, 16:17

Die Erweiterung heißt calendar_ical in der Version 3.1.3 unter CONTAO 3.5.33
und craffft/contao-calendar-ical-bundle in der Version dev-master#505fb8d6 unter CONTAO 4.4.13.

Beide zeigen das gleiche Verhalten wie in meinem langen Post beschrieben.

Froher FrankenGruß!

**Spooky** · 05.02.2018, 16:25

https://www.gartenbauverein-spalt.de...t%2Bladen.html » das funktioniert momentan auch mit FireFox nicht. Ich denke das hat was mit HTTP/2.0 zu tun.

**Spooky** · 05.02.2018, 16:26

Code:

$ curl -i https://www.gartenbauverein-spalt.de/kalender/ical/5/title/Den%2BKalender%2Bim%2BiCal%2BFormat%2Bladen.html
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   470    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
HTTP/2 200
server: nginx
date: Mon, 05 Feb 2018 15:25:50 GMT
content-type: text/calendar; charset=utf-8
content-length: 470
set-cookie: PHPSESSID=264100dd7b89b54dc3afc13060873d6a; path=/; HttpOnly
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: max-age=10
pragma: no-cache
content-disposition: attachment; filename="20180205162550.ics"


curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

**Spooky** · 05.02.2018, 16:52

Man müsste nun testen, ob man das auch ohne die calendar_ical Extension reproduzieren kann. Wenn nicht, könnte man sich mal die Header, die die calendar_ical Extension im Detail schicken will, genau ansehen. Und auch den Response Body, der zurück geschickt werden sollte. Es hat den Anschein als würde nginx, bevor der Response Body gesendet wird, abbrechen.

**Spooky** · 06.02.2018, 11:22

Kann es sein, dass da irgendwo ein Cache dazwischen hängt? Denn heute hat diese URL https://www.gartenbauverein-spalt.de...t%2Bladen.html einmal funktioniert - jetzt wieder nicht mehr. Leider habe ich keine Aufzeichnung der Response Header davon.

**allmächt!** · 06.02.2018, 13:59

Lieber Spooky,

auf deine Frage kann ich nur antworten: Es ist natürlich möglich. Aber leider weiß ich davon nix.
Und: es wäre doch ein sehr selektiver Cache, der nur die Auslieferung der .ics-Dateien verhindert und alles Andere duchlässt?

Grüße
Allmächt!

**Spooky** · 06.02.2018, 14:15

Zitat von allmächt!

Und: es wäre doch ein sehr selektiver Cache, der nur die Auslieferung der .ics-Dateien verhindert und alles Andere duchlässt?

Nein, du lädst da ja keine physische Datei runter. Die calendar_ical Extension (bzw. die iCalcreator library) erzeugt einfach einen entsprechenden Response.

**allmächt!** · 11.02.2018, 18:13

Guten Tag,

wenn ich den iCAL-Link zum Laden der Datei anklicke kommt bei Safari immer noch der Fehler NSPOSIXErrorDomain:100 und die Datei wird nicht geladen. (Datei = von CONTAO erzeugter Output)

Gleichzeitig wird zweimal ein PHP-Warning im error.log erzeugt:

[11-Feb-2018 15:22:23 Europe/Berlin]
PHP Warning: Cannot modify header information - headers already sent by (output started at /home/www/gartenbauverein-spalt.de/system/modules/ical_creator/vendor/lib/vcalendar.class.php:2075) in /home/www/gartenbauverein-spalt.de/system/modules/core/library/Contao/Template.php on line 294
#0 [internal function]: __error(2, 'Cannot modify h...', '/home/www/garte...', 294, Array)
#1 /home/www/gartenbauverein-spalt.de/system/modules/core/library/Contao/Template.php(294): header('Vary: User-Agen...', false)
#2 /home/www/gartenbauverein-spalt.de/system/modules/core/classes/FrontendTemplate.php(121): Contao\Template->output()
#3 /home/www/gartenbauverein-spalt.de/system/modules/core/pages/PageRegular.php(190): Contao\FrontendTemplate->output(true)
#4 /home/www/gartenbauverein-spalt.de/system/modules/core/controllers/FrontendIndex.php(285): Contao\PageRegular->generate(Object(Contao\PageModel), true)
#5 /home/www/gartenbauverein-spalt.de/index.php(20): Contao\FrontendIndex->run()
#6 {main}

[11-Feb-2018 15:22:23 Europe/Berlin]
PHP Warning: Cannot modify header information - headers already sent by (output started at /home/www/gartenbauverein-spalt.de/system/modules/ical_creator/vendor/lib/vcalendar.class.php:2075) in /home/www/gartenbauverein-spalt.de/system/modules/core/library/Contao/Template.php on line 295
#0 [internal function]: __error(2, 'Cannot modify h...', '/home/www/garte...', 295, Array)
#1 /home/www/gartenbauverein-spalt.de/system/modules/core/library/Contao/Template.php(295): header('Content-Type: t...')
#2 /home/www/gartenbauverein-spalt.de/system/modules/core/classes/FrontendTemplate.php(121): Contao\Template->output()
#3 /home/www/gartenbauverein-spalt.de/system/modules/core/pages/PageRegular.php(190): Contao\FrontendTemplate->output(true)
#4 /home/www/gartenbauverein-spalt.de/system/modules/core/controllers/FrontendIndex.php(285): Contao\PageRegular->generate(Object(Contao\PageModel), true)
#5 /home/www/gartenbauverein-spalt.de/index.php(20): Contao\FrontendIndex->run()
#6 {main}

Hat jemand der ehrenwerten Leser eine Ahnung, was hier nicht stimmt?

Grüße aus Mittelfranken-Süd :-)

**allmächt!** · 12.02.2018, 15:00

Guten Tag,

ich habe den Datenverkehr mit Wireshark aufgezeichnet und hier als .txt im Anhang drangesetzt. Es handelt sich in beiden Fällen um .csv-Dateien.

Einmal HV-Spalt.txt, die unverschlüsselte Seite (Hetzner), bei der der Kalender mit Safari geladen werden kann und
zum anderen GBV-Spalt.txt, der verschlüsselten Seite (WebGo), bei der Kalender mit Safari nicht geladen werden kann.

Der Mittschnitt hat alles vom Klick auf den Kalender-Lade-Link ab aufgezeichnet.

Leider kenne ich mich bei den Details nicht aus, doch ist für mich auffällig, dass im GBV-Spalt der Befehl "GET" nicht vorkommt, sondern nur "Application Data" verzeichnet ist. Aber vielleicht liegt das ja an HTTPS...

Und vielleicht weiß jemand darüber Bescheid.

Grüße