Während wir dabei sind, denke ich, dass die gesamten Netzwerkeinstellungen für Discourse irrelevant sind:
- IPv6-Kompatibilität kann nicht mehr deaktiviert werden, und natürlich ist Discourse nicht davon abhängig, sondern kann perfekt auf einem reinen IPv4-System laufen.
- IP-Geolokalisierung fügt den Header
CF-IPCountryzu Anfragen hinzu, der jedoch von Discourse nicht verwendet wird. Es verwendet eine eigene (optionale) MaxMind-Funktion. - Network Error Logging fügt den Antwortheader Report-To hinzu, den Browser zum Melden von Fehlern verwenden können. Er ist jedoch veraltet, und selbst wenn die Funktion mit allen Cloudflare-Plänen aktiviert werden kann, ist das Dashboard-Element zur tatsächlichen Anzeige der Berichte nur im Enterprise-Plan verfügbar. In diesem Fall könnte es für einige alte Browser lediglich eine Datenschutzregression und einen Netzwerk-Overhead darstellen.
- Onion Routing verbessert die Privatsphäre für Anfragen aus dem Tor-Netzwerk. Discourse kümmert sich nicht darum oder weiß es nicht einmal.
- Die Pseudo-IPv4-Funktion könnte sogar benötigt werden, wenn der Host Software wie alte Analysetools oder ähnliches ausführt, die nur IPv4-Adressen unterstützen. Die Proxy-Header von Cloudflare, wie
Cf-Connecting-IP(oder andere, je nach Konfiguration), können dann angepasst werden, um eine mehr oder weniger eindeutige IPv4-Adresse anstelle der tatsächlichen IPv6-Adresse des Clients zu erhalten, um die Tatsache zu umgehen, dass die IPv6-Unterstützung für Client-zu-Cloudflare-Anfragen nicht mehr deaktiviert werden kann. Auch hier kümmert sich Discourse nicht darum. Ich meine, es wäre ein Problem für z. B. die GeoIP-Erkennung, aber die Funktion ist standardmäßig deaktiviert, und Administratoren sollten sie natürlich nur aktivieren, wenn sie von der jeweiligen Software, die sie ausführen, unbedingt benötigt wird, und die Nachteile von nicht echten Client-IPs in Kauf nehmen. Sie kann auch so konfiguriert werden, dass nur ein neuer Header mit der Pseudo-IPv4-Adresse hinzugefügt wird, und Analysetools (oder was auch immer) können dann bei Bedarf Client-IP-Header überschreiben, während Anfragen an Discourse nicht betroffen wären. In jedem Fall ist die Funktion für die allgemeine Funktionalität von Discourse irrelevant. - True-Client-IP Header fügt zusätzlich zu
CF-Connecting-IPundX-Forwarded-Fornur diesen Header hinzu. Discourse verwendet ihn nicht, und auch die Discourse-Konfigurationsvorlage verwendet stattdessenCF-Connecting-IP. Daher hat er keine Auswirkung. - gRPC wird von Discourse nicht verwendet, aber es schadet auch nicht, wenn Cloudflare zum Weiterleiten von gRPC-Anfragen aktiviert ist, genauso wie bei WebSockets. Beide müssen möglicherweise für andere Software aktiviert sein, die auf derselben Cloudflare-Domäne läuft.
- Maximale Upload-Größe 100 MB ist Standard und Minimum. Größere Upload-Größen erfordern Business- oder Enterprise-Pläne, und Discourse wird nicht fehlschlagen, wenn Cloudflare größere Uploads zulässt.
Das Einzige, worüber ich mir nicht sicher bin, ob es Auswirkungen haben kann, ist Response Buffering. Und ich kann es nicht testen, da es eine reine Enterprise-Funktion ist. Aber ich kann mir nicht vorstellen, dass der Client sich darum kümmert, ob Pakete von der CF-Edge gestreamt werden, sobald sie eintreffen, oder ob sie in einem Stück gesendet werden, sobald sie an der Edge fertig sind. Für gecachte Daten (ich meine von Cloudflare gecachte Daten) geschieht dies ohnehin immer und verursacht zumindest keine Probleme. Diese Funktion betrifft nur nicht gecachte Daten.
Im Grunde würde ich also die gesamte Sektion “Netzwerkeinstellungen” entfernen, da sie für die Cloudflare-Funktionalität irrelevant ist, aber andere Software möglicherweise bestimmte Einstellungen erfordert oder Administratoren sie möglicherweise auf eine bestimmte Weise bevorzugen und wissen sollten, dass Discourse in jedem Fall funktioniert.