Ich habe gerade gemerkt, dass ich mit der .NET HttpWebRequest keine gzip'd-Inhalte vom Server bekommen habe (läuft nginx 0.8.52). Beim Testen mit curl habe ich überprüft, dass gzip serverseitig richtig eingerichtet wurde, dann habe ich mich mit dem VS-Debugger beschäftigt.
Der Täter stellt sich heraus, wie das Kopfzeilenfeld Accept-Encoding erzeugt wird: wenn ich
Ich bekomme folgende Überschrift:
%Vor%Wenn ich
einstelle %Vor%Ich bekomme
%Vor% Ich habe nicht überprüft, was die HTTP-Spezifikation sagt, aber nginx sollte die Situation behandeln, aber stattdessen gibt es Vary: Accept-Encoding zurück. Auf der anderen Seite sieht der Accept-Encoding Header, der von HttpWebRequest generiert wird, definitiv nicht richtig aus und scheint mir ein Fehler zu sein.
Wenn ich AutomaticDecompression nicht anführe und den Accept-Encoding Header manuell setze, bekomme ich gzip'd Inhalt zurück, aber HttpWebRequest scheint ziemlich dumm zu sein, und dekodiert den komprimierten Stream nicht (ich denke Es basiert auf einem internen IsCompressed -Flag, anstatt die Antwortheader zu analysieren.
Irgendwelche Vorschläge?
Es sollte angemerkt werden, dass es eine Authentifizierung gibt; Ich habe gerade herausgefunden, dass HttpWebRequest zunächst eine Anfrage ohne einschließlich der angegebenen Zugangsdaten durchführt. Für diese Anfrage wird der Header Accept-Encoding korrekt angegeben. Die Duplizierung tritt auf, nachdem die 401-Server-Antwort abgerufen und die Anforderung mit den Anmeldeinformationen erneut ausgeführt wurde.
Ich habe einen Fehlerbericht von Microsoft Connect veröffentlicht
Scheint ein Fehler zu sein. Mögliche Problemumgehungen:
LOL, witzigerweise erwähnen Sie das, ich habe das gerade am Freitag notiert; P
Ich habe deswegen keine Probleme gesehen, meine Antwort ist immer noch komprimiert.
Ich habe auch die verschiedenen Proxy-Anfragen zur Kenntnis genommen. Aber ich kann nicht für das Leben von mir GZip-Komprimierung arbeiten über MS ISA oder die neue mit dem Long-Name-Server. Es scheint nur den Header der Anfrage zu entfernen, und der Server weiß es nicht einmal. Ich werde mich morgen mit einem unserer Netzwerkadministratoren treffen, um zu sehen, ob es sich um einen Proxy handelt.
Aktualisierung:
Ich sollte beachten, dass ich kein Problem damit habe, einen Squid-Proxy zwischen mir und dem Server zu platzieren, aber das war einfach eine Standardauthentifizierung und nicht das ausgefallene Challenge-Response-Zeug, das Windows / ISA verwendet.
Update 2:
Ich habe vergessen zu erwähnen, dass der Accept-Encoding-Header auch verschwindet, wenn Sie einen Browser verwenden, um auf die Site zuzugreifen. Aus diesem Grund denke ich, dass das eigentliche Problem nicht spezifisch für .NET ist. Das Testen wird fortgesetzt.
Update 3:
Ich habe eine Aufnahme mit FF3.6 gemacht, die über den ISA-Proxy lief und ziemlich genau das gleiche Ergebnis. Über ISA wird nur ein "einzelner" Proxy authentifiziert, aber die endgültige Antwort ist immer noch nicht komprimiert.
Angesichts der hohen Rate erblicher Käfer bei MS-Produkten müsste ich mich dafür entscheiden, dass ISA / FTMG der Schuldige ist.
Ich hatte gerade das Meeting und löste das Problem (wird später Screenie mit der entsprechenden Einstellung veröffentlichen). Also die Ahnung war richtig (zumindest in meinem Fall).
Ich würde dringend empfehlen, in die ISA / FTMG-Konfiguration zu schauen, wenn diese im Netzwerk verwendet wird, das den Server hostet.
Update 5 (gelöst, wirklich):
Versuchte eine andere Einstellung, und das war der "Trick". Auf dem FTMG-Proxy mussten wir die HTTP-Komprimierung für das "externe" Netzwerk aktivieren und sicherstellen, dass die komprimierbaren Inhaltstypen korrekt waren (musste application / soap + xml für WCF hinzugefügt werden). Dies ermöglicht dem Proxy, eine Komprimierung durchzuführen, und der tatsächliche Webserver tut dies nicht, was zwar ideal ist oder nicht, aber zumindest funktioniert es. :)
Ich würde dringend empfehlen, in die ISA / FTMG-Konfiguration zu schauen, wenn diese im Netzwerk verwendet wird, das den Server hostet.
Protokoll erfassen:
Hier ist meine Spur, die die Seite mit IE8 über Forefront TMG-Proxy erfasst, der mit Wireshark erfasst wurde. Wenn der Fehler .NET-spezifisch ist, würde ich erwarten, dass das Ergebnis anders ist, aber von dem, was ich sehe, verhält es sich genauso.
Erste Anfrage:
%Vor%Authentifizieren mit Proxy, aber fehlschlägt?:
%Vor%Abschließende Sequenz:
%Vor%Tags und Links .net httpwebrequest