2016-01-27 21 views
12

Ho notato che alcuni siti di grandi nomi offrono JavaScript compresso e altri che non sono compressi, sullo stesso caricamento della pagina.Quando JavaScript NON deve essere gzip?

Ho anche read che JavaScript non deve essere gzip quando viene servito su https. Per eseguire il backup, ho notato che quando servi jQuery dal CDN di Google, lo servono solo da HTTP, ma non da HTTPS.

ad es. il primo è compresso; il secondo no.

http://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.min.js" 
https://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.min.js" 

Tuttavia, se si tira jQuery dalla Microsoft CDN su https:

https://ajax.aspnetcdn.com/ajax/jquery.mobile/1.3.2/jquery.mobile-1.3.2.min.js 

è servito compresso.

Esempi di grandi siti che servono sia compresso e non compresso sulla stessa caricamento della pagina, indipendentemente HTTPS o no:

Quindi la mia domanda è: quando dovrei gzip mia quando dovrei JavaScript e non?

Nota: la domanda a Can you use gzip over SSL? And Connection: Keep-Alive headers è un po 'simile, in quanto le risposte spiegano in quali circostanze NON è possibile utilizzare la compressione con HTTPS. Tuttavia, questa è solo metà della mia domanda: alcuni siti HTTP (non HTTPS) comprimono anche alcune ma non tutte le loro risorse javascript, ad es. l'esempio Stackoverflow menzionato sopra.

+1

Le cose menzionate hanno a che fare con il trasferimento di contenuto _secure_. Un sacco di javascript non è considerato sicuro (cioè è qualcosa che chiunque può ottenere semplicemente visitando la pagina), e quindi non degno di preoccupazione. Tuttavia, se stai servendo contenuti sicuri (ad esempio un carico utile json con informazioni identificabili), non dovresti gziparlo. – willaien

+0

@ willaien qualche idea di quali sarebbero le implicazioni quando è gzip'd? – charlietfl

+0

Credo che non dovrebbe essere gzip su https quando è necessario supportare IE6. Non ricordo dove l'ho letto, quindi lascerò questo come commento piuttosto che come risposta. – slebetman

risposta

4

Inizialmente pensavo che avesse qualcosa a che fare con il vecchio supporto del browser, perché infatti IE6 e Netscape4 avevano dei bug quando gestivano file js compressi. Ma questo non aveva nulla a che fare con HTTPS. Era la compressione stessa e i file di configurazione del server avevano a lungo impostazioni condizionali per non comprimere i file js se viene rilevato un browser precedente.

Dopo aver cercato su Google, si scopre che il problema non è con js. È con HTTPS. Non si dovrebbe pubblicare contenuto gzip su HTTPS/SPDY/HTTP2. Sono disponibili due attacchi quando viene offerto contenuto gzip su HTTPS: CRIME e BREACH.

Entrambi gli attacchi CRIME e BREACH si avvalgono del fatto che i dati gzipping riducono le loro dimensioni in modi statisticamente prevedibili. Entrambi gli attacchi sono in grado di estrarre i cookie che, a seconda di come funziona il tuo sito, consentono a un utente malintenzionato di accedere agli account utente.

Quindi dalla tua osservazione possiamo concludere che il CDN di Google è configurato correttamente.

Tuttavia, si noti come funzionano entrambi gli attacchi: il loro obiettivo finale è il dirottamento di sessione. Se stai scaricando un file js/css/gif da un server Microsoft, il tuo browser non invierà i cookie del tuo sito insieme alla richiesta (criterio della stessa origine). Quindi Microsoft può essere perdonato per aver fornito file js compressi su HTTPS.

Ciò significa che è possibile effettuare il file compressi su HTTPS!Devi solo assicurarti che quei file provengano da un dominio diverso per impedire che gli attacchi CRIME e BREACH provino a rubare i tuoi cookie.

+0

'content-encoding: gzip' --- questo è quello che vedo quando richiedo https://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.min.js – zerkms

+0

@zerkms: Hmm. Hai ragione – slebetman

+0

Per testare questo inizialmente, ho inserito questi due URL jQuery in tag di script in un documento html vuoto e ho esaminato la scheda di rete degli strumenti di sviluppo di Safari. Nella barra laterale destra, sotto "richiesta e risposta", "Compresso" è "No" per quest'ultimo. Facendolo in arricciatura inviando esplicitamente "Accept-Encoding: gzip" e sì anzi, torna compresso. È un browser predefinito non richiedere la compressione sulle risorse https? –

Problemi correlati