Domanda

Se il server web può inviare una risposta gzip, perché il browser non può inviare una richiesta gzip?

È stato utile?

Soluzione

Il client e il server devono concordare su come comunicare; parte di ciò è se la comunicazione può essere compressa. HTTP è stato progettato come modello di richiesta / risposta e quasi sicuramente la creazione originale prevedeva sempre piccole richieste e risposte potenzialmente grandi. La compressione non è richiesta per implementare HTTP, ci sono sia server che client che non la supportano.

La compressione HTTP è implementata dal client dicendo che può supportare la compressione e se il server lo vede nella richiesta e supporta la compressione può comprimere la risposta. Per comprimere la richiesta il cliente dovrebbe avere una "pre-richiesta" che in realtà ha negoziato che la richiesta sarebbe stata compressa o avrebbe dovuto richiedere la compressione come codifica supportata per TUTTE le richieste.

* AGGIORNAMENTO febbraio '17 * Sono passati 8 anni, ma come nota @ Phil_1984_, una terza soluzione possibile sarebbe quella per il client e il server di negoziare il supporto di compressione e quindi usarlo per le richieste successive. In effetti, cose come HSTS funzionano proprio in questo modo con la memorizzazione nella cache del client che il server prevede di parlare solo TLS e ignorare eventuali collegamenti non crittografati. HTTP è stato esplicitamente progettato per essere apolide ma a questo punto ci siamo spostati oltre.

Altri suggerimenti

Un client non può sapere in anticipo che un server capirà una richiesta gzip, ma il server può sapere che il client accetterà una richiesta.

Potrebbe, a condizione che possa garantire che il server lo accetti. Ciò potrebbe significare l'utilizzo di una richiesta OPTIONS.

Ci sono molte cose che i browser Web potrebbero fare (ad esempio, il pipelining) che non fanno. Gli sviluppatori di browser Web considerano le implicazioni di compatibilità di una modifica.

In un ambiente eterogeneo, ci sono molti server Web e configurazioni differenti. Apportare una modifica al modo in cui funziona un client potrebbe romperne alcuni.

Forse solo l'1% dei server potrebbe accettare richieste compresse, ma forse alcune di quelle pubblicizzano ciò che fanno, ma non possono accettarlo correttamente, quindi agli utenti verrebbe negato il caricamento di file su tali siti.

Storicamente ci sono state molte implementazioni client / server rotte - per lungo tempo, le risposte gzip sono state rotte nei principali browser Web (per fortuna quelli ora sono quasi scomparsi).

Quindi finiresti con blacklist di user-agent o server (o nomi di dominio) in cui quelle opzioni sono state automaticamente disattivate, il che è brutto.

Perché non sa che il server può accettarlo. Una transazione HTTP ha una singola richiesta inviata dal client seguita da una risposta. Una delle cose che il client invia è quale codifica / compressione può supportare. Il server può quindi decidere come comprimere la risposta. Il cliente non ha questo lusso.

Se stai scrivendo un'applicazione web, presumo che tu abbia il controllo di ciò che viene inviato al client e di ciò che viene restituito dal client.

Sarebbe abbastanza facile scrivere un'implementazione di gzip in javascript, che comprime i dati dei post inviati al server. Il server potrebbe avere un filtro (termine j2ee), che sa che i dati del client vengono inviati compressi, questo filtro decomprime i dati e quindi passa i dati al servlet (o alle classi di azioni in Struts) che leggono i dati normalmente, ad es. request.getParameter (...).

Questo sembra perfettamente logico e fattibile se hai il controllo. Come menzionano altri post, non puoi fare affidamento sul browser per farlo automaticamente, ma dal momento che stai scrivendo le pagine web, puoi far sì che il browser esegua la compressione che stai cercando (con un po 'di lavoro).

Andy.

HTTP è progettato in questo modo:

  • Il client dice la sua richiesta in testo semplice (incluso se riesco a capire le risposte compresse)
  • Il server risponde con la codifica del propper (compresso o meno)

MA IN QUESTO DISEGNO il client non può inviare richieste compresse perché non sa se il server lo capirà in anticipo.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top