Est-il possible d'activer la compression http pour les demandes?


35

Je vois beaucoup d'informations sur l'activation de la compression http pour les réponses du serveur mais également sur les demandes entrantes. Ne serait-il pas judicieux que les navigateurs compressent les articles de formulaire volumineux avant de les envoyer au serveur?

Un autre exemple est un service Web REST que nous utilisons. Nous devons envoyer des requêtes PUT fréquentes avec des fichiers XML volumineux (10+ Mo) et nous verrions certainement des avantages en termes de bande passante / vitesse des deux côtés.

Est-ce donc un problème résolu côté serveur ou chaque application Web doit-elle le gérer individuellement?

Réponses:


30

Pour que les PUTdonnées sur le serveur soient compressées, vous devez compresser le corps de la demande et définir l'en- Content-Encoding: gziptête. L'en-tête lui-même doit être décompressé. C'est documenté dans mod_deflate :

Le module mod_deflate fournit également un filtre pour décompresser un corps de requête compressé gzip. Pour activer cette fonctionnalité, vous devez insérer le filtre DEFLATE dans la chaîne de filtres d'entrée à l'aide de SetInputFilter ou AddInputFilter.

...

Désormais, si une requête contient un en-tête Content-Encoding: gzip, le corps sera automatiquement décompressé. Peu de navigateurs ont la capacité de gzip demander des corps. Cependant, certaines applications spéciales prennent en charge la compression des demandes, par exemple certains clients WebDAV.

Et un article le décrivant est ici :

Alors, comment fais-tu? Voici un texte de présentation, toujours issu du code source de mod_deflate: ne fonctionne que sur la requête principale / sans sous-requête. Cela signifie que le corps entier de la requête doit être compressé avec gzip si nous choisissons de l'utiliser, il n'est pas possible de compresser uniquement la partie contenant le fichier, par exemple dans une requête en plusieurs parties.

Séparément, un navigateur peut demander la compression du contenu de la réponse du serveur en définissant l'en- Accept-Encodingtête comme indiqué ci- dessous :

GET /index.html HTTP/1.1
Host: www.http-compression.com
Accept-Encoding: gzip
User-Agent: Firefox/1.0

Cela renverra les données compressées au navigateur.


5
+1 NB Vous écrivez you must compress the whole request, inclusive of header. Cependant, les en- têtes http ne doivent pas être compressés . La seule chose qui doit être compressée (dans son intégralité, comme l'indique correctement l'article que vous citez), est le corps http.
Eugene Beresovsky

1
Ceci est faux: Accept-Encodingindique au serveur la compression prise en charge par le client. L'en-tête Content-Encodingdécrit la compression du corps.
Maaartinus

@maaartinus voir première citation deuxième paragraphe. J'ai réorganisé la réponse pour plus de clarté.
Andy

4

Répondre à la partie sur les requêtes compressées, pas les réponses: oui, c'est possible, même si cela ne semble pas être utilisé à grande échelle. L'application côté client doit définir l'en-tête de codage du contenu approprié. En ce qui concerne l'application côté serveur, il y a 2 choix:

  1. l'application prend en charge la régénération du corps de la demande par elle-même. Un exemple de bibliothèque qui peut faire cela est celui de phpxmlrpc.

  2. le serveur Web gonfle le corps de la réponse avant de le transmettre à l'application. Ceci est possible en utilisant le filtre mod_deflate d'Apache et en configurant un inputFilter


2

Pas nativement de n'importe quel navigateur que je connaisse, vous devriez trouver un plugin qui le ferait pour vous. En gros, vous devez définir l'en-tête HTTP de codage de contenu pour que le serveur sache comment la requête parvient. Le serveur doit bien entendu être capable de gérer ce codage.


0

Ceci n'est pas autorisé. Selon la spécification HTTP ( RFC 2616 ), ce Content-Encodingn’est PAS l’un des champs d’en-tête de requête possibles; il est donc impossible de compresser le corps de l’entité de requête car il n’existe aucun moyen légal d’informer le serveur que cela s’est produit. Toute compression du corps de la demande est effectuée uniquement en tant qu'extension non standard.


12
Cette réponse est fausse RFC 2616 mentionne expressément que par If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type).ailleurs indiqué par Request and Response messages MAY transfer an entity if not otherwise restricted by the request methodet Content-EncodingCotée en optionentity-header
PeterT
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.