Ich stelle mir vor, allein schon vom Namen „Cloudflare Automatic HTTPS Rewrites“ kann man das missverstehen. Cloudflare hat 2 Funktionen:
- „Always Use HTTPS“ leitet alle einfachen HTTP-Anfragen an HTTPS weiter, ähnlich wie
force_httpsin Discourse. Beide waren zuvor aktiviert, und ich habe beide deaktiviert, um zu testen, ob HTTPS etwas mit dem Problem oder den endlosen Ladezeiten von Discourse-Seiten und hängendencurl-Anfragen zu tun hat. Dies funktionierte einwandfrei und löste sogar das gesamte Problem für HTTPS-Anfragen, aber nur, weil ich „Cloudflare Automatic HTTPS Rewrites“ im selben Zug deaktiviert habe. - „Cloudflare Automatic HTTPS Rewrites“ ändert HTML-, CSS- und JavaScript-Dokumente, um alle eingebetteten einfachen HTTP-URLs durch HTTPS-Varianten zu ersetzen, bei denen Cloudflare glaubt, dass der Host über HTTPS erreichbar ist (basierend auf der HSTS-Preload-Liste und ähnlichem). Dies soll Warnungen vor gemischtem Inhalt vermeiden.
Das Erzwingen oder Nicht-Erzwingen von HTTPS bei Cloudflare, beim Host-Proxy oder bei Discourse spielt keine Rolle. Was das Problem verursachte, war die Kombination des mod_sed-Filters beim Host-Proxy und die von Cloudflare bearbeiteten eingebetteten einfachen HTTP-Bearbeitungen. Also zwei Stufen, auf denen der Inhalt der Dokumente durch einen Filter geleitet wurde. Das Problem war nicht, dass es eine tatsächliche Inhaltsänderung gab (es gibt keinen gemischten Inhalt auf unserer Website, „Cloudflare Automatic HTTPS Rewrites“ ändert daher nicht tatsächlich den Dokumentenkörper), sondern wahrscheinlich im Zusammenhang mit Chunks, Puffern oder dem Timing.