Risiken beim Setzen von noCompressionForHttp10 und noCompressionForProxies auf false

Wir haben kürzlich für statische Inhalte zu Amazon Cloudfront gewechselt. Es scheint, dass Cloudfront HTTP 1.0-Anforderungen an den Ursprungsserver (IIS 7.0) mithilfe des Via-Headers ausführt. Standardmäßig deaktiviert IIS 7.0 die Dateikomprimierung für beide Optionen (HTTP 1.0- und Proxy-Anforderungen (Via)), die nur für den gesamten Server aktiviert werden können, indem noCompressionForHttp10 und noCompressionForProxies in applicationHost.config ( http: // msdn) auf false gesetzt werden .microsoft.com / de-de / library / ms690689 (v = vs.90) .aspx ).

Meine Frage ist: Wie hoch ist das Risiko, die Komprimierung für HTTP 1.0- und Proxy-Anforderungen zu aktivieren? Sind diese Einstellungen für WIRKLICH alte Browser / Proxys (z. B. Internet Explorer 5) gedacht oder besteht das Problem in neueren Browsern / Proxys?

Es sollte sicher sein, diese Optionen festzulegen.

Wenn man sich die Standardkonfiguration von Apache 2.2 in Ubuntu 12.04 (/etc/apache2/mods-available/deflate.conf) ansieht, sieht es so aus, als ob IE 6 einige Probleme mit der Komprimierung für CSS, RSS und Javascript hatte.

Außerdem unterstützen einige wirklich alte Proxys den 'Vary'-Header nicht und senden daher zwischengespeicherte, komprimierte Inhalte an Clients, die in ihrem' Accept'-Header keine Komprimierungsunterstützung angegeben haben.

Wenn Ihr Webserver NUR über das CDN aufgerufen wird, spielen diese beiden Optionen überhaupt keine Rolle. Wenn Sie weiterhin direkten Zugriff auf Ihren Webserver zulassen, können, wie Sie sagten, wirklich alte Browser / Proxys ein Problem haben (aber Benutzer solcher alten Produkte werden mit einer Reihe anderer Probleme konfrontiert sein ...)