Frage an iis-7, css, asp.net, content-encoding, content-type – IIS-Inhaltstyp für komprimiertes CSS falsch

3

Ich entwickle einen Teil einer ASP.NET-Site, die hauptsächlich Themen verwendet, aber einige CSS-Dateien im Themenordner enthält. Diese sind in der web.config von einem anderen Entwickler wie folgt enthalten:

<code><Content Include="App_Themes\SoftOrange\CMSStyles.css" />
<Content Include="App_Themes\SoftOrange\ContentStyles.css" />
</code>

Auf unserem internen Testserver (IIS7, Server 2008 R2 Enterprise) sind die globalen IIS-Manageroptionen für die statische und dynamische Komprimierung für Dateien mit mehr als 2700 Byte aktiviert. Die standortspezifische statische und dynamische Komprimierung sind ebenfalls aktiviert.

Irgendwann (wahrscheinlich als CMSStyles.css 2700 Bytes erreichte) wurden einige Stile gestopft - dh. wurden offensichtlich nicht durch einen Blick auf die Seite geladen. Ich fand heraus, dass der Inhaltstyp (gemäß Firefox 7.0.1) Text / CSS anzeigt, und als ich die URL für CMSStyles.css lud, sah es aus wie normaler komprimierter Müll in einem Texteditor:

‹�����
usw. IE öffnet die CSS-Datei nicht direkt, aber wenn ich Entwicklertools verwende, um die CSS anzuzeigen, erscheint sie leer.

Ich habe die statische Inhaltskomprimierung nur für diese Website deaktiviert und die CSS-Dateien werden jetzt ordnungsgemäß geladen. Meine Frage ist warum ?! Handelt es sich um ein inhaltliches Problem, eine Inhaltscodierung, oder handelt es sich um ein IIS-Problem oder um ein Problem mit der Verwendung von CSS in der Webanwendung?

Vielen Dank.

BEARBEITEN:

Dies sind die Header für die GET-Anforderung für CMSStyles.css: Response-Header

Accept-Ranges  bytes
Content-Encoding    gzip
Content-Length  1728
Content-Type    text/css
Date    Fri, 13 Apr 2012 01:22:43 GMT
Etag    "80a762a82cecd1:0"
Last-Modified   Fri, 30 Mar 2012 04:22:03 GMT
Persistent-Auth true
Server  Microsoft-IIS/7.5
Vary    Accept-Encoding
X-Powered-By    ASP.NET

Header anfordern

Accept text/css,*/*;q=0.1
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding gzip, deflate
Accept-Language en-gb,en;q=0.5
Connection  keep-alive
Cookie  -removed-
Host    -removed-
Referer -removed-
User-Agent  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1

es sieht also so aus, als ob die inhaltskodierung corrent: gzip ist.

Verwenden Sie ein Tool wie Firebug (oder die integrierten Chrome-Tools), um die HTTP-Header anzuzeigen, und finden Sie möglicherweise die Antwort. Tim Medora
danke, wusste nicht, dass du das im Net Panel machen kannst. Ich habe meinen Beitrag mit Überschriften aktualisiert. thinkOfaNumber

Deine Antwort

1   die antwort
1

dieContent-Length.

Überprüfen Sie, ob Sie dieContent-Length Entfernen Sie ihn in einem beliebigen Teil Ihres Codes, damit er wieder funktioniert. Warum das ? denn wenn du das einstellstContent-Length Beim Header kann der IIS ihn dann nicht in den komprimierten ändern, und die Dekomprimierung des gzip schlägt fehl. Warum kann IIS das nicht ändern? Wenn Sie einen Header in IIS festlegen, bleibt dieser Header standardmäßig erhalten und kann nicht geändert werden (insbesondere, wenn Sie ihn vorzeitig löschen). Es gibt ein Flag, mit dem IIS es ändern kann, nachdem Sie es festgelegt haben, aber es ist besser, es nur zu vermeiden, es festzulegen.

Ähnliche Fragen:ASP.NET-Site friert manchmal beim Laden auf Servern mit Lastenausgleich ein und / oder zeigt ungeraden Text oben auf der Seite an

Aktualisieren

Aus der @thinkOfaNumber: Es stellt sich herausIch habe sowohl die devexpress-Komprimierung als auch die IIS-Komprimierung verwendet. Ich habe die devexpress-Komprimierung in der web.config ausgeschaltet und es funktioniert!

Was hier gezeigt wird ist, dass der erste Druckverformungsrest derContent-Length und die zweite Komprimierung kann es nicht ändern, weilContent-Length Wird auf Header geschrieben und Header kann nicht geändert werden *, nachdem Sie ihn festgelegt haben. Daher ändert die zweite Komprimierung die endgültige komprimierte Seite mit dem Ergebnis, dass der Browser sie nicht richtig liest und sie dann nicht richtig dekomprimiert.

[*] Es gibt eine Möglichkeit, die Header zu ändern, nachdem Sie sie auf IIS gesendet haben und bevor Sie sie an den Browser senden. Dies kann durch Ändern des Standardverhaltens von IIS geschehen, ist jedoch nicht so einfach und ich weiß nicht, ob kann dieses Problem lösen.

Ihre letzte "Vermutung" war richtig - Es stellte sich heraus, dass ich sowohl die devexpress-Komprimierung als auch die IIS-Komprimierung verwendet habe. Ich habe die devexpress-Komprimierung in der web.config ausgeschaltet und es funktioniert! Sollte ich meine eigene Antwort darauf geben oder Ihre markieren? thinkOfaNumber
@thinkOfaNumber Akzeptiere diesen besser, weil ich eigentlich sage, dass das Problem die doppelte Komprimierung ist und die Länge des Inhalts nicht geändert werden kann. Deshalb habe ich meine Frage mit Ihren Angaben aktualisiert. Aristos
Ich stelle es nirgendwo programmatisch ein. Seltsamerweise sind die Zahlen immer gleich (1728 oder 1297) und man ist immer kaputt, man arbeitet immer ... thinkOfaNumber
@thinkOfaNumber Vielleicht hat es ein Modul gesetzt, oder vielleicht gibt es eine doppelte Komprimierung ... aus zwei verschiedenen Modulen. Aristos

Verwandte Fragen