mod_gzip - servir du contenu compressé par le serveur web Apache - Page 2

Auteur : Michael Schröpl

Communication en HTTP

Pour la transmission de contenus web entre le serveur et le client, le Protocole de Transfert Hypertexte (HTTP) est utilisé.

La communication fonctionne de la manière suivante :

1. Le client envoie une requête au serveur. Cette requête se compose principalement de headers HTTP qui décrivent quelles données le client souhaite recevoir.
   Dans une certaine mesure, le client est capable de influencer directement le contenu des données (comme spécifier l’URL de la page demandée) ; d’autres parties de sa requête fournissent au serveur des informations supplémentaires sur le type de données que le client préférerait recevoir, si le serveur doit offrir plusieurs variations de données.
2. Le serveur évalue toutes les informations disponibles pour décider quelles données avec quels types d’attributs ont été demandées et tente ensuite de servir ces données sous une forme la plus adaptée à la requête du client.
   Ce paquet de données contient à nouveau des headers HTTP mais principalement des données - qui ne peuvent néanmoins être interprétées que partiellement sans tenir compte des headers HTTP.

Le deuxième aspect de la détermination du contenu souhaité est nommé Négociation de Contenu dans sa forme générale. La livraison de contenu de page compressé sous la forme décrite ici est également basée sur ce principe général.

Encodages en HTTP

HTTP 1.1 définit dans le chapitre 3.5 les soi-disant encodages de contenu qui devraient être supportés par chaque navigateur conforme à cette norme.

Pour la communication entre le serveur et le client, ces encodages ont la signification suivante :

1. Ce client peut spécifier une liste d’encodages de contenu acceptés dans le header HTTP Accept-Encoding :. L’identité d’encodage spéciale (décrivant un encodage qui ne change pas le contenu) sera utilisée implicitement comme valeur par défaut.
2. Le serveur devrait livrer le contenu du document demandé en utilisant un encodage accepté par ce client.
   Si le serveur n’est pas capable de le faire, il devrait rejeter la requête avec le code d’état 406 Not Acceptable ; néanmoins, il peut livrer des contenus non acceptables pour ce client selon sa requête (et dont le traitement pourrait causer des problèmes insolubles pour le client).
   Le serveur web Apache utilise une stratégie défensive à cet égard : s’il ne peut pas servir une page selon les demandes du client mais a plusieurs autres variantes à offrir, il génère dynamiquement un document HTML contenant une brève description de la situation et des liens vers tous les documents en question. (C’est également le cas si ce document précis est demandé par un navigateur qui n’accepte aucune des langues de et en supportées par moi-même selon sa configuration actuelle ; j’ai délibérément pas défini de valeur par défaut pour rendre ce problème conscient aux lecteurs de langue étrangère de ces pages.)

Si un serveur sert un fichier contenant un encodage à un client incapable de le gérer, alors ce client pourrait ne pas être en mesure de le traiter correctement.

Emplacement original de ce document :

http://www.schroepl.net/projekte/mod_gzip/encoding.htm