From: Lucien Gentis Date: Thu, 4 Jan 2018 16:54:38 +0000 (+0000) Subject: Adding new french translated XML file. X-Git-Tag: 2.5.0-alpha2-ci-test-only~2999 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=1b8800d59b9d4f8576fbced0189dddce0d1a57c8;p=thirdparty%2Fapache%2Fhttpd.git Adding new french translated XML file. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1820130 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_filter.xml.fr b/docs/manual/mod/mod_filter.xml.fr new file mode 100644 index 00000000000..ed12ea95253 --- /dev/null +++ b/docs/manual/mod/mod_filter.xml.fr @@ -0,0 +1,535 @@ + + + + + + + + + + + +mod_filter +Module de configuration de filtre intelligent sensible au +contexte +Base +mod_filter.c +filter_module + + +

Ce module permet une configuration intelligente et dépendant du + contexte des filtres de contenu en sortie. Par exemple, Apache peut + être configuré pour faire traiter différents types de contenus par + différents filtres, même lorsque le type de contenu n'est pas connu + à l'avance (par exemple dans un serveur mandataire).

+ +

Le fonctionnement de mod_filter consiste à + introduire des branchements dans la chaîne de filtrage. Plutôt que + d'insérer directement des filtres dans la chaîne, on insère un + sélecteur de filtre qui va effectuer un branchement conditionnel + vers un fournisseur de filtre. mod_filter peut + utiliser tout filtre de contenu comme fournisseur ; aucune + modification des modules de filtrage existants n'est nécessaire + (bien qu'il soit tout de même possible de les simplifier).

+ + +
Filtrage intelligent +

Dans le modèle de filtrage traditionnel, les filtres sont insérés + sans condition à l'aide de la directive AddOutputFilter et des directives + apparentées. Chaque filtre doit ensuite déterminer s'il doit + s'exécuter ou non, et les administrateurs du serveur disposent de + peu de souplesse pour faire en sorte que la chaîne soit traitée de + manière dynamique.

+ +

mod_filter, à l'opposé, fournit aux + administrateurs du serveur un grand degré de souplesse pour + configurer la chaîne de filtrage. Concrètement, la décision + d'insérer un filtre peut être prise en fonction d'une expression booléenne complexe. Ceci + généralise le fonctionnement relativement souple de la directive + AddOutputFilterByType.

+
+ +
Déclarations de filtres, fournisseurs et +chaînes +

+ [Cette image illustre le modèle de filtrage traditionnel]
+ Figure 1: Le modèle de filtrage traditionnel

+ +

Dans le modèle traditionnel, les filtres en sortie constituent + une simple chaîne s'étendant depuis le générateur de contenu (ou + gestionnaire) jusqu'au client. Ce fonctionnement peut convenir s'il + permet d'atteindre le but recherché, mais pose + problème lorsque cette chaîne doit être configurée dynamiquement en + fonction de la sortie du gestionnaire.

+ +

+ [Cette image illustre le modèle de fonctionnement de + mod_filter]
+ Figure 2: Le modèle de fonctionnement de + mod_filter

+ +

Le fonctionnement de mod_filter consiste à + introduire des branchements dans la chaîne de filtrage. Plutôt que + d'insérer directement des filtres dans la chaîne, on insère un + sélecteur de filtre qui va effectuer un branchement conditionnel + vers un fournisseur de filtre. mod_filter peut + utiliser tout filtre de contenu comme fournisseur ; aucune + modification des modules de filtrage existants n'est nécessaire + (bien qu'il soit tout de même possible de les simplifier). Il peut y + avoir plusieurs fournisseurs pour un seul filtre, mais un seul + fournisseur sera choisi pour chaque requête.

+ +

Une chaîne de filtrage peut comporter autant d'instances du + sélecteur de filtre que l'on souhaite, chacune d'entre elles pouvant + disposer de plusieurs fournisseurs. Un sélecteur de filtre possédant + un seul fournisseur dont le choix est inconditionnel constitue un + cas particulier : cette situation est équivalente à l'insertion + directe du filtre dans la chaîne.

+
+ +
Configuration de la chaîne de +filtrage +

Trois étapes sont nécessaires pour configurer une chaîne de + filtrage avec mod_filter. Voir ci-dessous la + description détaillée des directives.

+ +
+
Déclaration des filtres
+
La directive FilterDeclare permet de déclarer un + filtre en lui assignant un nom et un type. Elle n'est obligatoire + que si le filtre n'est pas du type par défaut + AP_FTYPE_RESOURCE.
+ +
Enregistrement des fournisseurs
+
La directive FilterProvider permet d'associer un + fournisseur à un filtre. Le filtre a été éventuellement déclaré à + l'aide de la directive FilterDeclare ; si ce n'est pas le cas, FilterProvider + va le déclarer implicitement avec le type par défaut + AP_FTYPE_RESOURCE. Le fournisseur doit avoir été enregistré à + l'aide de ap_register_output_filter par un module + quelconque. Le dernier argument de la directive FilterProvider est une expression : + le fournisseur s'exécutera pour une requête si et seulement si + l'expression est évaluée vraie. L'expression peut évaluer une + requête HTTP ou les en-têtes de la réponse, des variables + d'environnement, ou le gestionnaire utilisé par cette requête. À la + différence des version précédentes, mod_filter supporte désormais + les expressions complexes associant des critères multiples au moyen + d'une logique AND / OR (&& / ||) et de parenthèses. Pour les + détails sur la syntaxe de l'expression, voir la documentation sur ap_expr.
+ +
Configuration de la chaîne de filtrage
+
Les directives ci-dessus permettent d'élaborer les éléments + d'une chaîne de filtrage intelligente, mais pas de les configurer en + vue de leur exécution. La directive FilterChain élabore une chaîne de filtrage à + partir de filtres intelligents déclarés, permettant avec souplesse + d'insérer des filtres au début ou à la fin de la chaîne, de + supprimer un filtre ou même la chaîne complète.
+
+
+
Filtrage et statut de la réponse +

Normalement, mod_filter n'applique les filtres qu'aux réponses + possédant un statut HTTP 200 (OK). Pour pouvoir filtrer des + documents possédant un autre statut, vous devez définir la variable + d'environnement filter-errordocs, les réponses étant + alors filtrées sans se préoccuper de leur statut. Pour définir ce + comportement de manière plus fine, vous pouvez utiliser des + conditions dans la directive + FilterProvider.

+
+
Mise à jour depuis une configuration du +serveur HTTP Apache 2.2 +

La directive FilterProvider a été modifiée par + rapport à httpd 2.2 : les arguments match et + dispatch ont été remplacés par l'argument unique + expression plus polyvalent. En général, il est possible + de convertir une paire match/dispatch vers les deux côtés d'une + expression, de la manière suivante :

+ "dispatch = 'match'" +

Les en-têtes de requête et de réponse et les variables + d'environnement sont maintenant interprétés selon les syntaxes + respectives %{req:foo}, %{resp:foo} et + %{env:foo}. Les variables %{HANDLER} et + %{CONTENT_TYPE} sont également supportées.

+

Notez que l'évaluation de l'expression ne supporte plus les + comparaisons de sous-chaînes. Ces dernières peuvent + être remplacées par des comparaisons d'expressions rationnelles.

+
+ +
Exemples +
+
Inclusions côté serveur (SSI)
+
Un exemple simple de remplacement de la directive AddOutputFilterByType + +FilterDeclare SSI +FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|" +FilterChain SSI + +
+ +
Inclusions côté serveur (SSI)
+
Même exemple que ci-dessus, mais envoi vers un gestionnaire + (comportement classique des SSI ; les fichiers .shtml sont + traités). + +FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'" +FilterChain SSI + +
+ +
Émulation de mod_gzip avec mod_deflate
+
Insertion du filtre INFLATE seulement si l'en-tête + Accept-Encoding a une valeur autre que "gzip". Ce filtre s'exécute + avec le type ftype CONTENT_SET. + +FilterDeclare gzip CONTENT_SET +FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/" +FilterChain gzip + +
+ +
Diminution de la résolution d'une image
+
Supposons que nous voulions réduire la résolution de toutes les + images web, et que nous disposions de filtres pour les images GIF, + JPEG et PNG. + +FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'" +FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'" +FilterProvider unpack png_unpack "%{CONTENT_TYPE} = 'image/png'" + +FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|" +FilterProtocol downsample "change=yes" + +FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'" +FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'" +FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'" +<Location "/image-filter"> + FilterChain unpack downsample repack +</Location> + +
+
+
+ +
Gestion de protocole +

Historiquement, tout filtre doit s'assurer que toute modification + qu'il effectue est correctement représentée dans les en-têtes de la + réponse HTTP, et qu'il ne s'exécutera pas si cette exécution + résultait en une modification interdite. Ceci impose aux auteurs de + filtres la corvée de réimplémenter certaines fonctionnalités + communes dans chaque filtre :

+ +
    +
  • De nombreux filtres modifient les contenus, et de ce fait + invalident les balises de ces contenus, leur somme de + contrôle, leur condensé (hash) existant, ainsi que leur + taille.
    • + +
  • Les filtres qui nécessitent une réponse entière et non tronquée en + entrée, doivent s'assurer qu'il n'ont pas reçu une réponse à une + requête partielle.
    • + +
  • Les filtres qui modifient la sortie d'un autre filtre doivent + s'assurer qu'ils ne violent pas la directive d'un en-tête + Cache-Control: no-transform éventuel.
    • + +
  • Les filtres peuvent agir sur des réponses de façon à ce qu'elles + ne puissent plus être mises en cache.
    • +
+ +

mod_filter a pour but de gérer de manière + générale ces détails de l'implémentation des filtres, réduisant par + là-même la complexité des modules de filtrage de contenu. Le + travail permettant d'atteindre ce but est cependant toujours en + cours ; la directive FilterProtocol + implémente certaines de ces fonctionnalités à des fins de + compatibilité ascendante avec les modules d'Apache 2.0. Pour les + versions 2.1 et supérieures de httpd, les API + ap_register_output_filter_protocol et + ap_filter_protocol permettent aux modules de filtrage + de définir leurs propres comportements.

+ +

Cependant, mod_filter ne doit pas interférer + avec un filtre qui gère déjà tous les aspects du protocole. Par + défaut (c'est à dire en l'absence de toute directive FilterProtocol), + mod_filter ne modifiera donc pas les en-têtes.

+ +

Au moment où ces lignes sont écrites, cette fonctionnalité a été + très peu testée, car les modules d'usage courant ont été conçus pour + fonctionner avec httpd 2.0. Les modules qui l'utilisent devront donc + l'expérimenter avec précautions.

+
+ + +AddOutputFilterByType +assigne un filtre en sortie pour un type de média +particulier +AddOutputFilterByType filtre[;filtre...] +type_de_média [type_de_média] ... +server config +virtual hostdirectory +.htaccess +FileInfo +Présentait de sévères limitations avant d'être déplacé dans +mod_filter dans la version 2.3.7 + + +

Cette directive active un filtre en sortie particulier pour une + requête en fonction du type de média de la réponse.

+ +

L'exemple suivant active le filtre DEFLATE qui est + fourni par le module mod_deflate. Il va compresser + toute sortie dont le type MIME est text/html ou + text/plain avant de l'envoyer au client.

+ + + AddOutputFilterByType DEFLATE text/html text/plain + + +

Si vous voulez assigner plusieurs filtres au contenu, leurs noms + doivent être séparés par des points-virgules. On peut aussi utiliser + une directive AddOutputFilterByType pour + chacun des filtres à assigner.

+ +

La configuration ci-dessous impose le traitement de toute sortie + de script dont le type MIME est text/html en premier + lieu par le filtre INCLUDES, puis par le filtre + DEFLATE.

+ + +<Location "/cgi-bin/"> + Options Includes + AddOutputFilterByType INCLUDES;DEFLATE text/html +</Location> + + + + +AddOutputFilter +SetOutputFilter +Les filtres + + + +FilterDeclare +Déclare un filtre intelligent +FilterDeclare nom_filtre [type] +server configvirtual host +directory.htaccess +Options + + +

Cette directive permet de déclarer un filtre en sortie associé à + un en-tête ou une variable d'environnement qui déterminera les + conditions de son exécution. Le premier argument est le nom du + filtre destiné à être utilisé dans les directives FilterProvider, FilterChain et FilterProtocol.

+ +

Le dernier argument (optionnel) est le type du filtre, et peut + prendre les valeurs de ap_filter_type, à savoir + RESOURCE (valeur par défaut), CONTENT_SET, + PROTOCOL, TRANSCODE, + CONNECTION ou NETWORK.

+ + + + +FilterProvider +Enregistre un filtre de contenu +FilterProvider nom_filtre nom_fournisseur + expression +server configvirtual host +directory.htaccess +Options + + +

Cette directive permet d'associer un fournisseur au + filtre intelligent. Le fournisseur sera invoqué si et seulement si + l'expression est évaluée vraie lorsque le sélecteur de + filtre est appelé pour la première fois.

+ +

+ nom fournisseur doit avoir été enregistré au cours du + chargement d'un module à l'aide de + ap_register_output_filter. +

+ +

expression est une expression ap_expr.

+ + +Les expressions dans le serveur HTTP +Apache, pour une référence complète et d'autres exemples. +mod_include + + + +FilterChain +Configure la chaîne de filtrage +FilterChain [+=-@!]nom_filtre ... +server configvirtual host +directory.htaccess +Options + + +

Cette directive permet de configurer une chaîne de filtrage + composée de filtres déclarés. FilterChain + accepte un nombre illimité d'arguments, chacun d'entre eux étant + précédé d'un caractère de contrôle unique qui détermine l'action à + entreprendre :

+ +
+
+nom filtre
+
Ajoutenom filtre à la fin de la chaîne de filtrage
+ +
@nom filtre
+
Ajoute nom filtre au début de la chaîne de filtrage
+ +
-nom filtre
+
Supprime nom filtre de la chaîne de filtrage
+ +
=nom filtre
+
Supprime tous les filtres de la chaîne de filtrage existante et + les remplace par nom filtre
+ +
!
+
Supprime tous les filtres de la chaîne de filtrage existante
+ +
nom filtre
+
Équivalent à +nom filtre
+
+ + + + +FilterProtocol +Vérifie le respect du protocole HTTP +FilterProtocol nom_filtre [nom_fournisseur] + drapeaux_protocole +server configvirtual host +directory.htaccess +Options + + +

Cette directive permet à mod_filter de s'assurer + qu'un filtre ne s'exécutera pas s'il ne doit pas le faire, et que + les en-têtes de la réponse HTTP sont définis correctement en tenant + compte des effets du filtre.

+ +

Cette directive se présente sous deux formes. Avec trois + arguments, elle s'applique de manière spécifique à un nom + filtre et un nom fournisseur pour ce filtre. Avec + deux arguments, elle s'applique à un nom filtre pour + tout fournisseur qu'il actionne.

+ +

Les drapeaux spécifiés sont fusionnés avec les drapeaux que les + fournisseurs sous-jacents ont éventuellement enregistrés avec + mod_filter. Par exemple, un filtre peut avoir + spécifié en interne un drapeau équivalent à change=yes, + mais une configuration particulière du module peut le surcharger + en spécifiant change=no. +

+ +

drapeaux_protocole peut contenir un ou plusieurs + drapeaux parmi les suivants :

+ +
+
change=yes|no
+
Indique si le filtre doit modifier le contenu, y compris éventuellement sa + taille
+ +
change=1:1
+
Le filtre modifie le contenu, mais pas sa taille
+ +
byteranges=no
+
Le filtre ne peut pas traiter de réponses à des sous-requêtes et + nécessite des réponses complètes en entrée
+ +
proxy=no
+
Le filtre ne doit pas s'exécuter dans un contexte de mandataire
+ +
proxy=transform
+
Le filtre transforme la réponse de manière incompatible avec + l'en-tête HTTP Cache-Control: no-transform
+ +
cache=no
+
Le filtre fait en sorte que la sortie ne puisse pas être mise en + cache (par exemple en introduisant des modifications de contenu + aléatoires)
+
+ + + + +FilterTrace +Obtention d'informations de débogage/diagnostique en +provenance de mod_filter +FilterTrace nom_filtre niveau +server configvirtual host +directory + + +

Cette directive permet d'obtenir des informations de débogage en + provenance de mod_filter. Elle est conçue pour + aider à tester et déboguer les fournisseurs (ou modules de filtrage) + ; elle peut aussi apporter une aide à l'utilisation de + mod_filter lui-même.

+ +

La sortie de débogage dépend de la définition d'argument + level :

+
+
0 (valeur par défaut)
+
Aucune information de débogage n'est générée.
+ +
1
+
mod_filter va enregistrer les ensembles de + conteneurs de données (buckets and brigades) qui traversent le + filtre dans le journal des erreurs, avant que le fournisseur ne les + traite. Ces informations sont similaires à celles générées par mod_diagnostics. +
+ +
2 (pas encore implémenté)
+
Ce niveau permettra d'enregistrer l'ensemble des données qui + traversent le filtre dans un fichier temporaire avant de les envoyer + au fournisseur. Pour un débogage mono-utilisateur + seulement ; l'enregistrement des données concernant + plusieurs requêtes simultannées ne sera pas supporté.
+
+ + + + +