2012-12-06 11 views
15

Myślałem, że to proste wyszukiwanie w Google, ale najwyraźniej się mylę.Co to jest metoda kanoniczna dla klienta HTTP, która nakazuje serwerowi HTTP wyłączenie odpowiedzi Gzip?

Widziałem, że należy dostarczyć:

Accept-Encoding: gzip;q=0,deflate;q=0 

w nagłówkach żądań. Jednak artykuł, który zasugerował, zauważył również, że proxy rutynowo ignoruje ten nagłówek. Ponadto, gdy podałem go do nginx, nadal kompresował treść wiadomości odpowiedzi.

http://forgetmenotes.blogspot.ca/2009/05/how-to-disable-gzip-compression-in.html

Tak, jak mówię serwer WWW, aby wyłączyć kompresję w treści wiadomości odpowiedź?

+0

Jestem zdezorientowany: czy chcesz wysłać dyrektywę z klienta do serwera, czy chcesz coś, co jest gwarantowane, aby przejść przez to, czy niechętny serwer proxy może być przeszkodą, czy też dyrektywa nakazuje serwerowi, aby nie kompresował pod żadnym pozorem? – fvu

+0

Drugi ... Chcę, żeby dyrektywa nakazała serwerowi, aby nie kompresował pod żadnym pozorem. – Homer6

+0

Należy pamiętać, że aby zapobiec wszystkim uciskom, prawdopodobnie będziesz chciał użyć '*; q = 0' zamiast tylko zabraniać gzip i deflacji. To powiedziawszy, rzeczywiście myślę, że wiele serwerów nie przejmuje się funkcją Accept-Encoding, tak jak powinny. Istnieje również "Accept-Encoding: identity" ... –

Odpowiedz

10

Czy chcesz kodowania zostać całkowicie wyłączone?
Następnie należy pominąć nagłówek Accept-Encoding w nagłówkach żądań http.

Czy chcesz, aby kompresja gzip była nieobecna w odpowiedzi na http?
Następnie pomiń gzip z listy wartości w nagłówku żądania http.

Czy chcesz nadać priorytet różnym technikom kompresji obsługiwanym przez serwery? następnie użyj różnych wartości od 0 do 1 wzdłuż - z argumentem q dla każdej wartości w nagłówku żądania HTTP Accept-Encoding.(Obecnie używasz sprzecznej wartości i wskazujesz wagowo = 0, że nie wiesz, jak sobie poradzisz, ale chcesz, aby odpowiedź była zakodowana).

+1

Dla serwerów proxy, które uwzględniają nagłówek HTTP Accept-Encoding dla treści obsługiwanych z ich pamięci podręcznej, nagłówek odpowiedzi HTTP Vary jest używany z nagłówkami żądań http, takimi jak Accept-Encoding jako lista wartości, więc proxy wie, że kopia przechowywana w pamięci podręcznej różni się w zależności od który nagłówek żądania http. –

+2

NIE NIE NIE. Specyfikacja W3C (https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3) CLEARLY stwierdza, że ​​"Jeśli w żądaniu nie ma pola Accept-Encoding, serwer MOŻE założyć, że klient zaakceptuje wszelkie kodowanie treści. " Ponadto "Uwaga: Jeśli żądanie nie zawiera pola Accept-Encoding, a kodowanie treści" identity "jest niedostępne, to kodowania treści powszechnie rozumiane przez klientów HTTP/1.0 (np." Gzip "i" compress ") są preferowane; " – roryhewitt

+1

https://tools.ietf.org/html/rfc2616#section-14.3 Brakowało tymczasowego zdania "W tym przypadku, , jeśli" tożsamość "jest jednym z dostępnych kodowań treści, serwer POWINIEN używać" tożsamość "kodowanie treści, o ile nie ma ona dodatkowej informacji, że inne kodowanie treści ma dla klienta znaczenie" "., więc notatka jest tylko ostatecznością co najwyżej. Również IETF jest organem kanonicznym w zakresie protokołów internetowych, w tym http, a w czasie tej odpowiedzi http1.1 był normą. Dla ciekawskich i skrajnych przypadków, takich jak twoje, domyślam się, że link jest taki, jak w tym komentarzu. –

13

Wiele serwerów internetowych ignoruje parametr "q". Skompresowana wersja statycznego zasobu jest często buforowana i jest zwracana, gdy tylko zaakceptuje to żądanie. Aby uniknąć pobierania skompresowanych zasobów, należy użyć serwera, który nie powinien obsługiwać skompresowanej reprezentacji zasobu w tym wystąpieniu. Nie powinien też być pełnomocnik. Jest to domyślne akceptowane kodowanie, jeśli żadna nie jest podana, ale twój klient może dodać domyślną akceptację gzip, więc jawne dostarczanie "tożsamości" powinno załatwić sprawę.

+0

Niestety, nginx nie wydaje się tego przestrzegać. Nadal wracam do gzipu. – Homer6

+1

Należy pamiętać, że żadne "Accept-Encoding" nie jest równoznaczne z tożsamością. Dokumentacja wyraźnie mówi, że serwer może zdecydować, co zrobić, jeśli kodowanie nie zostało określone. –

3

myślę, że ten mod dla apache

http://httpd.apache.org/docs/2.2/mod/mod_deflate.html (2)

A to dla Nginx

http://wiki.nginx.org/HttpGzipModule (1)

Wygląda na to, czego potrzebujesz w zależności od serwera planujecie posługiwać się. Reszta należy do Ciebie!

Uwaga modułu nginx zarówno umożliwia zamykanie dekompresji:

[edit] gzip 
Syntax: gzip on | off 
Default: off 
Context: http 
server 
location 
if in location 
Reference: gzip 



Enables or disables gzip compression. 

i radzenia sobie z proxy:

[edit] gzip_proxied 
Syntax: gzip_proxied off | expired | no-cache | no-store | private | no_last_modified | no_etag | auth | any ... 
Default: off 
Context: http 
server 
location 
Reference: gzip_proxied 



It allows or disallows the compression of the response for the proxy request in the dependence on the request and the response. The fact that, request proxy, is determined on the basis of line "Via" in the headers of request. In the directive it is possible to indicate simultaneously several parameters: 

off - disables compression for all proxied requests 
expired - enables compression, if the "Expires" header prevents caching 
no-cache - enables compression if "Cache-Control" header is set to "no-cache" 
no-store - enables compression if "Cache-Control" header is set to "no-store" 
private - enables compression if "Cache-Control" header is set to "private" 
no_last_modified - enables compression if "Last-Modified" isn't set 
no_etag - enables compression if there is no "ETag" header 
auth - enables compression if there is an "Authorization" header 
any - enables compression for all requests 
[edit] gzip_types 

najlepsze życzenia!

Źródła:

1) http://forum.nginx.org/read.php?11,96472,214303

2) http://httpd.apache.org/docs/2.2/mod/mod_deflate.html#inflate (Sekcja wyjściowa dekompresyjne)

Powiązane problemy