Potrzebujesz pomocy z niektórymi ustawieniami kompresji web.config IIS7

Próbuję skonfigurować ustawienia kompresji IIS7 w pliku web.config. Próbuję włączyć gzip do żądań HTTP 1.0.

MSDN ma tutaj wszystkie informacje na ten temat .

Czy jest możliwe umieszczenie tych informacji konfiguracyjnych w pliku web.config mojej witryny? Czy muszę ustawić go na poziomie aplikacji? Obecnie mam ten kod w moim web.config ...

<system.webServer>
    <urlCompression 
        doDynamicCompression="true" 
        dynamicCompressionBeforeCache="true" />
    <httpCompression 
        cacheControlHeader="max-age=86400" 
        noCompressionForHttp10="False" 
        noCompressionForProxies="False" 
        sendCacheHeaders="true" />

    ... other stuff snipped ...

</system.webServer>

To nie działa :( Żądania HTTP 1.1 są kompresowane, tylko nie 1.0.

Ta strona MSDN powyżej mówi, że można jej użyć w:

• Machine.config
• ApplicationHost.config
• Aplikacja root Web.config
• Aplikacja Web.config
• Katalog Web.config

Czy możemy zatem ustawić te ustawienia dla poszczególnych witryn, programowo w pliku web.config? (jest to plik Web.config aplikacji ...) Co zrobiłem źle?

Twoje zdrowie :)

EDYCJA: Zostałem zapytany, skąd wiem, że HTTP1.0 nie jest kompresowany. Korzystam z reguł śledzenia nieudanych żądań, które zgłaszają:

DYNAMIC_COMPRESSION_START
DYNAMIC_COMPRESSION_NOT_SUCESS
    Reason: 3
    Reason: NO_COMPRESSION_10
DYNAMIC_COMPRESSION_END

Zwróć szczególną uwagę na fakt, że ustawienie web.config IIS 7.x

noCompressionForProxies="false"

Nie jest honorowany na poziomie web.config. Musi być ustawiony w C: \ Windows \ System32 \ inetsrv \ config \ ApplicationHost.config w następujący sposób:

<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files" noCompressionForProxies="False">

Upewnij się i wykonaj reset IIS po zmianie ustawienia.

Żądanie jest wysyłane z serwera proxy przez IIS, jeśli żądanie internetowe klienta ma nagłówek HTTP „Via” w następujący sposób:

Via: 1.1 foo

Po kilku badaniach jest domyślnie „zablokowany” na poziomie aplikacji. Jako taki musi zostać „odblokowany”. można to osiągnąć za pomocą wiersza polecenia lub (dodatkowe pobieranie) narzędzi administracyjnych iis7.

na przykład. appcmd set config -section:urlCompression /doDynamicCompression:true

Refrences:

• Zmiany kompresji w IIS7
• Kompresja dynamiczna HowTo

W jaki sposób testujesz, czy żądania HTTP1.0 nie są kompresowane? Czy to możliwe, że klient, którego używasz, nie informuje serwera, że ​​może zaakceptować skompresowaną odpowiedź?

Jeśli widzisz nagłówki wysłane przez klienta (przedstawione przez samego klienta testowego, używając Firebug lub podobnego narzędzia, jeśli testujesz w Firefoksie lub IEHTTPHeaders, jeśli testujesz w IE, lub poprzez wąchanie ruchu za pomocą zewnętrznego narzędzia), powinieneś zobaczyć coś takiego

Accept-Encoding: compress, gzip, deflate

gdzieś tam. Jeśli klient nie poinformuje serwera, że ​​może zaakceptować skompresowaną odpowiedź, serwer nie wyśle ​​jej bez względu na inne ustawienia, które masz po stronie serwera.

Innym problemem może być testowanie przez serwer proxy, który sam się zidentyfikował. W takim przypadku ustawienie noCompressionForProxies może mieć pierwszeństwo i blokować możliwość skompresowanej odpowiedzi.

Należy zauważyć, że niektórzy klienci i serwery proxy, które wysyłają żądania HTTP1.0 (zwykle starsze oprogramowanie) nie będą poprawnie obsługiwały skompresowanej odpowiedzi, jeśli ją otrzymają, więc jeśli włączysz kompresję odpowiedzi na żądania HTTP1.0, upewnij się, że przetestuj swoją witrynę / aplikację we wszystkich programach klienckich / proxy, których oczekują użytkownicy / użytkownicy. Jest to mniejszy problem, jeśli możesz zagwarantować, że twoi odbiorcy będą używać określonego oprogramowania (jeśli na przykład aplikacja jest przeznaczona tylko do wewnętrznej sieci korporacyjnej), ale w przeciwnym razie istnieje wiele kombinacji do przetestowania, dlatego większość serwerów wyłącza kompresję dla 1.0 wniosków całkowicie.