Perché Chrome richiede il download di una pagina come file .gz sui collegamenti ipertestuali, ma non inserisco manualmente l'URL?

Question

Ho appena scoperto un comportamento molto strano su Chrome mentre cercavo di accedere ad alcune pagine. Si richiederà di scaricarli come file .gz invece di caricarli.

questo accade solo con Chrome in corso e su tutte le piattaforme.

Quando la pagina viene caricata correttamente posso vedere questo sul Ispettore

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

so che queste sono serviti da un server nginx che è configurato per utilizzare la compressione gzip, ma non c'è nulla di sbagliato in questo.

gzip on; # that's on nginx part 

Sono quasi sicuro che si tratti di qualcosa di sbagliato nella configurazione di nginx, ma cosa?

Ciò che rende il problema ancora più interessante (e fastidioso) è che se si copia l'URL dal collegamento e incollarlo al browser sarà solo aprire la pagina in modo corretto. Sì, questo succede solo su collegamenti ipertestuali.

ho cercato di trovare un bug report su Chrome su questo, ma l'unica cosa che sono riuscito a trovare è che altri hanno fatto segnalare una simile se non lo stesso problema con le pagine reddit o github.com quelli.

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

ho sperimentato lo stesso comportamento e inviato anche un report per gli sviluppatori di Chrome. Nel frattempo ho disabilitato tutte le mie estensioni di Chrome e non ho più riconosciuto il comportamento. Mi sembra strano, perché funziona bene ieri.

EDIT: ho trovato il cromo causando estensione. Nel mio caso era "Hover Zoom". Qualsiasi altra estensione installata (Adblock, PageSpeed, Tweetdeck e così via) funziona correttamente e senza il problema del "download .gz file". Il dev sta lavorando su questo problema (https://code.google.com/p/hoverzoom/issues/detail?id=489)

EDIT2: Non uso più HoverZoom, perché l'estensione è ora spyware (dai un'occhiata a https://code.google.com/p/hoverzoom/issues/detail?id=489#c16). Invece di Hover-Zoom ora sto usando Hover-Free (https://chrome.google.com/webstore/detail/hover-free/hcmnnggnaofmhflgomfjfbndngdoogkj/related). Spero che ti aiuti. Grazie a Caschy (http://stadt-bremerhaven.de/chrome-erweiterung-hoverzoom-sendet-heimlich-daten/)

Answer 2

Ha avuto anche questo problema. Ho trovato una soluzione modificando htaccess del mio sito Wordpress, costringendo tipi di file specifici a caricare così com'è;

<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> 

Penso che sia un problema di plug-in di cache del sito. Nel mio caso, WPSuperCache

Answer 3

Ho avuto lo stesso problema e semplicemente l'Content-Type nell'intestazione della risposta era errato. Per controllare la Content-Type goto la scheda di rete nei tool di sviluppo di Google Chrome (F12) e vedere i Type colonne. Molto probabilmente è qualcosa come binary o gzip.

Per risolvere il problema aggiungere due cose alla configurazione Nginx:

1. ho avuto i file precompresse così hanno dovuto assicurarsi che il server invia la corretta Content-Type (quello che su un server web Apache sarebbe il ForceType directive). Vedi How do I serve pre-gzipped files with nginx so that they'll be shown as text in the browser?

   Per questo è necessario il modulo HttpGzipStatic.

2. Aggiungi gzip_vary on. Vedi StackPath: Accept-Encoding: It's Vary Important:

   Immaginate due client: un vecchio browser senza compressione e uno moderno con esso. Se entrambi richiedono la stessa pagina, a seconda di chi ha inviato la richiesta per prima, la versione compressa o non compressa verrà archiviata nella CDN. Ora iniziano i problemi: il vecchio browser potrebbe richiedere un normale "index.html" e ottenere la versione compressa, compressa (dati spazzatura casuali), oppure il nuovo browser potrebbe ottenere la versione cache non compressa e provare a "decomprimerlo". Cattive notizie, in entrambi i casi.

   La correzione è per il server di origine per rispedire Vary: Accept-Encoding

Riferimenti

• 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?