Warum fordert Chrome zum Herunterladen einer Seite als .gz-Datei auf Hyperlinks auf, aber ich gebe die URL nicht manuell ein?

Question

Ich habe gerade ein sehr merkwürdiges Verhalten in Chrome entdeckt, als ich versuchte, auf einige Seiten zuzugreifen. Es wird aufgefordert, sie als .gz Dateien herunterzuladen, anstatt sie zu laden.

Dies geschieht nur mit aktuellen Chrome und auf allen Plattformen.

Wenn die Seite richtig geladen ich dies auf dem

Inspector sehen

Resource interpreted as Document but transferred with MIME type application/x-gzip: „https://confluence.example.com/display/engp/PR-1221“.

Ich weiß, dass diese von einem Nginx-Server bedient werden, der für die Verwendung von GZIP-Komprimierung konfiguriert ist, aber daran ist nichts falsch.

gzip on; # that's on nginx part 

Ich bin mir fast sicher, das ist etwas falsch mit Nginx-Konfiguration, aber was?

Was das Problem noch interessanter (und ärgerlicher) macht, ist, dass, wenn Sie die URL vom Hyperlink kopieren und in den Browser einfügen, wird sie nur die Seite korrekt öffnen. Ja, das passiert nur auf Hyperlinks.

Ich habe versucht, einen Fehlerbericht auf Chrom auf diesem zu finden, aber das einzige, was ich finden konnte, ist, dass andere ähnliche, wenn nicht das gleiche Problem mit Reddit-Seiten oder github.com Einsen gemeldet haben.

Request URL:https://confluence.example.com/display/engp/PR-1221 
Request Method:GET 
Status Code:200 OK 
Request Headersview source 
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Charset:UTF-8,*;q=0.5 
Accept-Encoding:gzip,deflate,sdch 
Accept-Language:en-US,en;q=0.8 
Connection:keep-alive 
DNT:1 
Host:example.com 
Referer:https://example.com/browse/PR-1221 
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22 

 
Response Headersview source 
Access-Control-Allow-Credentials:true 
Access-Control-Allow-Headers:DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type 
Access-Control-Allow-Methods:GET, POST, OPTIONS, HEAD 
Access-Control-Allow-Origin:* 
Baz:bah 
Cache-Control:no-cache, must-revalidate 
Connection:keep-alive 
Content-Encoding:gzip 
Content-Type:text/html;charset=UTF-8 
Date:Mon, 04 Mar 2013 13:29:48 GMT 
Expires:Thu, 01 Jan 1970 00:00:00 GMT 
Foo:bar 
Server:nginx/1.2.6 
Transfer-Encoding:chunked 
X-Confluence-Request-Time:1362403788150 
X-Seraph-LoginReason:OK 

Answer 1

erleben ich das gleiche Verhalten und auch einen Bericht an die Chrom Devs gesendet. Inzwischen habe ich alle meine Chrome-Erweiterungen deaktiviert und das Verhalten nicht mehr erkannt. Fühlt sich irgendwie komisch an, weil es gestern gut funktioniert.

EDIT: Ich fand das Chrom verursacht Erweiterung. In meinem Fall war es "Hover Zoom". Jede andere installierte Erweiterung (Adblock, PageSpeed, Tweetdeck usw.) funktioniert einwandfrei und ohne das Problem ".gz Datei herunterladen". Der Entwickler arbeitet an diesem Problem (https://code.google.com/p/hoverzoom/issues/detail?id=489)

EDIT2: Ich verwende HoverZoom nicht mehr, weil die Erweiterung jetzt Spyware ist (werfen Sie einen Blick auf https://code.google.com/p/hoverzoom/issues/detail?id=489#c16). Anstelle von Hover-Zoom verwende ich jetzt Hover-Free (https://chrome.google.com/webstore/detail/hover-free/hcmnnggnaofmhflgomfjfbndngdoogkj/related). Hoffe das hilft dir. Danke an Caschy (http://stadt-bremerhaven.de/chrome-erweiterung-hoverzoom-sendet-heimlich-daten/)

Answer 2

Hatte dieses Problem auch. Ich habe eine Lösung gefunden, indem ich htaccess auf meiner Wordpress-Site bearbeitet habe, um bestimmte Dateitypen so zu laden, wie sie sind;

<IfModule mod_mime.c> 
AddCharset utf-8 .html 
AddCharset utf-8 .json 
AddEncoding gzip .gz 
</IfModule> 
<FilesMatch "(\.html|\.html\.gz)$"> 
ForceType text/html 
</FilesMatch> 
<FilesMatch "(\.json|\.json\.gz)$"> 
ForceType text/javascript 
</FilesMatch> 

Ich denke, es ist ein Problem der Website Caching-Plugins. In meinem Fall WPSuperCache

Answer 3

Ich hatte das gleiche Problem und einfach die Content-Type im Antwortheader war falsch. Um die Content-Type zu überprüfen, gehen Sie auf die Registerkarte Netzwerk in Google Chrome Entwickler-Tools (F12) und sehen Sie die Type Spalten. Wahrscheinlich ist es so etwas wie binary oder gzip.

Um Ihr Problem fügen Sie zwei Dinge auf Ihre NGINX Konfiguration zu lösen:

1. Ich hatte vorverdichtete Dateien mußten so dass der Server wäre die richtigen Content-Type (was auf einem Apache Web-Server sendet die ForceType directive). Siehe How do I serve pre-gzipped files with nginx so that they'll be shown as text in the browser?

   Sie benötigen dafür das Modul HttpGzipStatic.

2. Hinzufügen gzip_vary on. Siehe StackPath: Accept-Encoding: It's Vary Important:

   Stellen Sie sich zwei Clients vor: einen alten Browser ohne Komprimierung und einen modernen damit. Wenn beide die gleiche Seite anfordern, wird abhängig davon, wer zuerst die Anfrage gesendet hat, die komprimierte oder unkomprimierte Version im CDN gespeichert. Jetzt fangen die Probleme an: Der alte Browser könnte nach einem regulären "index.html" fragen und die gecachete, komprimierte Version (zufällige Junk-Daten) holen, oder der neue Browser könnte die zwischengespeicherte, unkomprimierte Version bekommen und versuchen, sie zu "entpacken". Schlechte Nachrichten, so oder so.

   Das Update ist für den Ursprungsserver zurück zu senden Vary: Accept-Encoding

Referenzen

• How can I tell if my server is serving GZipped content?
• What 'Content-Type' header to use when serving gzipped files?
• Google Developers: Web Fundamentals: Optimizing Encoding and Transfer Size of Text-Based Assets
• NGINX: Module ngx_http_gzip_module
• NGINX: COMPRESSION AND DECOMPRESSION
• Is Vary: Accept-Encoding overkill?