Ich bin nicht ganz sicher, ob dies auf SO gehört, aber ich weiß nicht, wo ich sonst fragen soll.

Während ich die Ladegeschwindigkeit einer meiner Web-Apps überprüfte, bemerkte ich, dass anscheinend keine HTTP-Antwort (egal welcher Typ - html, css, js) gzip / deflate-komprimiert ist. Das heißt, in keiner Anforderung ist ein Antwortheader wie "Content-Encoding: gzip" vorhanden, und der Browser meldet, dass die Ressource nicht komprimiert ist.

getestet und bestätigt in mehreren Browsern (IE10, FF 17, Chrome 23, Opera 12.10, Safari 5.x)Getestet und bestätigt auf zwei Computern mit Windows 8 ProMit Fiddler doppelt geprüft - Die Antwort ist nicht komprimiert und enthält keinen inhaltskodierenden HeaderDies geschieht nicht nur für meine Web-Apps,Nein andere von mir getestete Website sendet anscheinend komprimierte Antworten (laut Browser)Unter Windows 7 kommen die Antworten komprimiert und mit allen Headern anHTTPS-Antwortensind komprimiert

Hier ist ein Beispiel für die Antwortheader (beachten Sie das Fehlen des Inhaltscodierungs-Headers):

Ich habe auch die Serverseite überprüft. Auf dem Server wird Windows Server 2008 R2 / IIS 7.5 ausgeführt. Ich habe die Ablaufverfolgung für fehlgeschlagene Anforderungen verwendet, um herauszufinden, was der Server sendet. Die Ressource scheint komprimiert zu sein:

Außerdem scheint der Server die richtigen Header zu senden:

Mein Fazit: Es muss Windows 8 sein, das hier eingreift. Anscheinend ändert es HTTP-Antworten. Ich nehme an, Windows 8 empfängt die komprimierte Antwort, dekomprimiert sie, entfernt den Header für die Inhaltscodierung und leitet die geänderte Antwort weiter in der Pipeline.

Nun meine Fragen:

Kann jemand bestätigen, dass Windows 8 HTTP-Antworten ändert und dass es so funktioniert, wie ich es beschrieben habe?Gibt es eine Möglichkeit, dieses Verhalten zu überwachen oder sogar zu deaktivieren?

Vielen Dank im Voraus für Ihre Antworten.

Grüße, Andre

Update: Ich habe Wireshark benutzt, um zu sehen, was auf dem Client ankommt. Wie erwartet sind die Ressourcen komprimiert und der Header für die Inhaltskodierung ist noch vorhanden. Das Bild unten zeigt das Wireshark-Protokoll und rechts unten die von Chrome empfangene Antwort.

Dies bestätigt meine Annahme, dass Windows 8 interveniert.