From: Rich Bowen Date: Tue, 13 Feb 2018 14:24:53 +0000 (+0000) Subject: Adding newly generated .fr docs. X-Git-Tag: 2.5.0-alpha2-ci-test-only~2874 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=319e2a46edd81b4964d0d5ec590a335d830f4daa;p=thirdparty%2Fapache%2Fhttpd.git Adding newly generated .fr docs. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1824140 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_authnz_fcgi.html.fr b/docs/manual/mod/mod_authnz_fcgi.html.fr new file mode 100644 index 00000000000..2e6c886ca81 --- /dev/null +++ b/docs/manual/mod/mod_authnz_fcgi.html.fr @@ -0,0 +1,589 @@ + + + + + +mod_authnz_fcgi - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+
+Apache > Serveur HTTP > Documentation > Version 2.5 > Modules
+
+

Module Apache mod_authnz_fcgi

+
+

Langues Disponibles:  en  | + fr 

+
+ + + + +
Description:Permet à une application d'autorisation FastCGI de gérer +l'authentification et l'autorisation httpd.
Statut:Extension
Identificateur de Module:authnz_fcgi_module
Fichier Source:mod_authnz_fcgi.c
Compatibilité:Disponible à partir de la version 2.4.10 du serveur HTTP +Apache
+

Sommaire

+ +

Ce module permet aux applications d'autorisation FastCGI + d'authentifier les utilisateurs et de contrôler leur accès aux + ressources. Il supporte les systèmes d'autorisation FastCGI + génériques qui participent en une seule phase à l'authentification + et à l'autorisation, ainsi que les processus d'authentification et + d'autorisation spécifiques à Apache httpd qui interviennent en une + ou plusieurs phases.

+ +

Les processus d'autorisation FastCGI peuvent authentifier un + utilisateur via son identificateur et son mot de passe comme dans le + processus d'authentification basique, ou via un mécanisme + arbitraire.

+
+ +
top
+
+

Modes d'invocation

+ +

Les modes d'invocation des processus d'autorisation FastCGI que + ce module supporte se distinguent par deux caractéristiques : le + type et le mécanisme d'authentification.

+ +

Le Type est simplement authn pour + l'authentification, authz pour l'autorisation et + authnz l'authentification et l'autorisation.

+ +

Le mécanisme d'authentification fait référence aux + mécanismes d'authentification et aux phases de traitement de la + configuration de Apache httpd, et peut être + AuthBasicProvider, Require, ou + check_user_id. Les deux premiers mécanismes + correspondent aux directives utilisées pour participer aux phases de + traitement appropriées.

+ +

Description de chaque mode:

+ +
+
Type authn, mechanism + AuthBasicProvider
+ +
Dans ce mode, la variable FCGI_ROLE est définie à + AUTHORIZER, et la variable + FCGI_APACHE_ROLE à AUTHENTICATOR. + L'application doit être spécifiée en tant que fournisseur de type + authn via la directive AuthnzFcgiDefineProvider, et + activée via la directive AuthBasicProvider. Lorsqu'elle + est invoquée, l'application est censée authentifier le client à + l'aide de l'identifiant et du mot de passe de l'utilisateur. + Exemple d'application : + +
#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+    die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHENTICATOR";
+    die if $ENV{'FCGI_ROLE'}        ne "AUTHORIZER";
+    die if !$ENV{'REMOTE_PASSWD'};
+    die if !$ENV{'REMOTE_USER'};
+
+    print STDERR "This text is written to the web server error log.\n";
+
+    if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+        $ENV{'REMOTE_PASSWD'} eq "bar" ) {
+        print "Status: 200\n";
+        print "Variable-AUTHN_1: authn_01\n";
+        print "Variable-AUTHN_2: authn_02\n";
+        print "\n";
+    }
+    else {
+        print "Status: 401\n\n";
+    }
+}
+ + + Exemple de configuration httpd : +
AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10102/
+<Location "/protected/">
+  AuthType Basic
+  AuthName "Restricted"
+  AuthBasicProvider FooAuthn
+  Require ...
+</Location>
+ +
+ +
Type authz, mechanism + Require
+
Dans ce mode, la variable FCGI_ROLE est définie à + AUTHORIZER et FCGI_APACHE_ROLE à + AUTHORIZER. L'application doit être spécifiée en tant + que fournisseur de type authz via la directive AuthnzFcgiDefineProvider. + Lorsqu'elle est invoquée, l'application est censée contrôler les + accès du client à l'aide de l'identifiant utilisateur et d'autres + données contenues dans la requête. Exemple d'application : +
#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+    die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHORIZER";
+    die if $ENV{'FCGI_ROLE'}        ne "AUTHORIZER";
+    die if $ENV{'REMOTE_PASSWD'};
+
+    print STDERR "This text is written to the web server error log.\n";
+
+    if ($ENV{'REMOTE_USER'} eq "foo1") {
+        print "Status: 200\n";
+        print "Variable-AUTHZ_1: authz_01\n";
+        print "Variable-AUTHZ_2: authz_02\n";
+        print "\n";
+    }
+    else {
+        print "Status: 403\n\n";
+    }
+}
+ + + Exemple de configuration httpd : +
AuthnzFcgiDefineProvider authz FooAuthz fcgi://localhost:10103/
+<Location "/protected/">
+  AuthType ...
+  AuthName ...
+  AuthBasicProvider ...
+  Require FooAuthz
+</Location>
+ +
+ +
Type authnz, mechanism + AuthBasicProvider + Require
+ +
Dans ce mode qui supporte le protocole d'autorisation web + server-agnostic FastCGI, la variable FCGI_ROLE est + définie à AUTHORIZER et FCGI_APACHE_ROLE + n'est pas définie. L'application doit être spécifiée en tant que + fournisseur de type authnz via la directive AuthnzFcgiDefineProvider. + L'application est censée assurer l'authentification et + l'autorisation au cours d'une même invocation à l'aide de + l'identifiant et du mot de passe de l'utilisateur et d'autres + données contenues dans la requête. L'invocation de l'application + intervient au cours de la phase d'authentification de l'API Apache + httpd. Si l'application renvoie le code 200, et si le même + fournisseur est invoqué au cours de la phase d'autorisation (via + une directive Require), mod_authnz_fcgi + renverra un code de type success pour la phase d'autorisation sans + invoquer l'application. Exemple d'application : +
#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+    die if $ENV{'FCGI_APACHE_ROLE'};
+    die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+    die if !$ENV{'REMOTE_PASSWD'};
+    die if !$ENV{'REMOTE_USER'};
+
+    print STDERR "This text is written to the web server error log.\n";
+
+    if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+        $ENV{'REMOTE_PASSWD'} eq "bar" &&
+        $ENV{'REQUEST_URI'} =~ m%/bar/.*%) {
+        print "Status: 200\n";
+        print "Variable-AUTHNZ_1: authnz_01\n";
+        print "Variable-AUTHNZ_2: authnz_02\n";
+        print "\n";
+    }
+    else {
+        print "Status: 401\n\n";
+    }
+}
+ + + Exemple de configuration httpd : +
AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/
+<Location "/protected/">
+  AuthType Basic
+  AuthName "Restricted"
+  AuthBasicProvider FooAuthnz
+  Require FooAuthnz
+</Location>
+ +
+ +
Type authn, mechanism + check_user_id
+ +
Dans ce mode, la variable FCGI_ROLE est définie à + AUTHORIZER et FCGI_APACHE_ROLE à + AUTHENTICATOR. L'application doit être spécifiée en + tant que fournisseur de type authn via une directive + AuthnzFcgiDefineProvider. La + directive AuthnzFcgiCheckAuthnProvider + permet de l'invoquer. Exemple d'application : +
#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+    die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHENTICATOR";
+    die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+
+    # This authorizer assumes that the RequireBasicAuth option of
+    # AuthnzFcgiCheckAuthnProvider is On:
+    die if !$ENV{'REMOTE_PASSWD'};
+    die if !$ENV{'REMOTE_USER'};
+
+    print STDERR "This text is written to the web server error log.\n";
+
+    if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+        $ENV{'REMOTE_PASSWD'} eq "bar" ) {
+        print "Status: 200\n";
+        print "Variable-AUTHNZ_1: authnz_01\n";
+        print "Variable-AUTHNZ_2: authnz_02\n";
+        print "\n";
+    }
+    else {
+        print "Status: 401\n\n";
+        # If a response body is written here, it will be returned to
+        # the client.
+    }
+}
+ + + Exemple de configuration httpd : +
AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10103/
+<Location "/protected/">
+  AuthType ...
+  AuthName ...
+  AuthnzFcgiCheckAuthnProvider FooAuthn \
+                               Authoritative On \
+                               RequireBasicAuth Off \
+                               UserExpr "%{reqenv:REMOTE_USER}"
+  Require ...
+</Location>
+ +
+ +
+ +
top
+
+

Exemples supplémentaires

+ +
    +
  1. Si votre application supporte séparément les rôles + d'authentification et d'autorisation (AUTHENTICATOR et + AUTHORIZER), vous pouvez définir des fournisseurs + séparés comme suit, même s'ils correspondent à la même application : + +
    AuthnzFcgiDefineProvider authn  FooAuthn  fcgi://localhost:10102/
+AuthnzFcgiDefineProvider authz  FooAuthz  fcgi://localhost:10102/
    + + + Spécifie le fournisseur authn via la directive + AuthBasicProvider + et le fournisseur authz via la directive + Require: + +
    AuthType Basic
+AuthName "Restricted"
+AuthBasicProvider FooAuthn
+Require FooAuthz
    + +
    2. + +
  2. Si votre application supporte le rôle générique + AUTHORIZER (authentification et autorisation en une + seule invocation), vous pouvez définir un fournisseur unique comme + suit : + +
    AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/
    + + + Spécifie le fournisseur authnz via les directives + AuthBasicProvider et + Require : + +
    AuthType Basic
+AuthName "Restricted"
+AuthBasicProvider FooAuthnz
+Require FooAuthnz
    + +
    3. +
+
top
+
+

Limitations

+ +

Les fonctionnalités suivantes ne sont pas encore implémentées :

+ +
+
Vérificateur d'accès d'Apache httpd
+
La phase access check de l'API Apache httpd est + distincte des phases d'authentification et d'autorisation. + Certaines autres implémentations de FastCGI supportent cette phase + et lorsque c'est le cas, la variable FCGI_APACHE_ROLE + est définie à ACCESS_CHECKER.
+ +
Redirections (pipes) ou sockets locaux (Unix)
+
Seuls les sockets TCP sont actuellement supportés.
+ +
Support de mod_authn_socache
+
Le support de l'interaction avec mod_authn_socache pour les + applications qui interviennent dans le processus + d'authentification d'Apache httpd serait souhaitable.
+ +
Support de l'authentification de type digest à l'aide de AuthDigestProvider
+
Cette limitation ne sera probablement jamais franchie car il + n'existe aucun flux de données d'autorisation capable de lire dans + un condensé de type hash.
+ +
Gestion des processus applicatifs
+
Cette fonctionnalité restera probablement hors de portée de ce + module. Il faudra donc gérer les processus applicatifs d'une autre + manière ; par exemple, fcgistarter permet de + les démarrer.
+ +
AP_AUTH_INTERNAL_PER_URI
+
Tous les fournisseurs sont actuellement enregistrés en tant + que AP_AUTH_INTERNAL_PER_CONF, ce qui signifie que les + vérifications ne sont pas effectuées pour les + sous-requêtes internes avec la même configuration de contrôle + d'accès que la requête initiale.
+ +
Conversion du jeu de caractères des données de protocole
+
Si mod_authnz_fcgi s'exécute dans un environnement de + compilation EBCDIC, toutes les données de protocole FastCGI sont + écrites en EBCDIC et doivent être disponibles en EBCDIC.
+ +
Plusieurs requêtes pour une connexion
+
Actuellement, la connexion au fournisseur d'autorisation + FastCGI est fermée après chaque phase de traitement. Par exemple, + si le fournisseur d'autorisation gère séparément les phases + authn et authz, deux connexions seront + nécessaires.
+ +
Redirection de certains URIs
+
Les URIs en provenance des clients ne peuvent pas être + redirigés selon une table de redirection, comme avec la directive + ProxyPass utilisée avec les répondeurs + FastCGI.
+ +
+ +
top
+
+

Journalisation

+ +
    +
  1. Les erreurs de traitement sont journalisées à un niveau + error ou supérieur.
    2. +
  2. Les messages envoyés par l'application sont journalisés au + niveau warn.
    3. +
  3. Les messages de deboguage à caractère général sont + journalisés au niveau debug.
    4. +
  4. Les variables d'environnement transmises à l'application + sont journalisées au niveau trace2. La valeur de la + variable REMOTE_PASSWD sera occultée, mais + toute autre donnée sensible sera visible dans le + journal.
    5. +
  5. Toutes les entrées/sorties entre le module et l'application + FastCGI, y compris les variables d'environnement, seront + journalisées au format imprimable et hexadécimal au niveau + trace5. Toutes les données sensibles seront + visibles dans le journal.
    6. +
+ +

La directive LogLevel permet + de configurer un niveau de journalisation spécifique à + mod_authnz_fcgi. Par exemple :

+ +
LogLevel info authnz_fcgi:trace8
+ + +
+
top
+

Directive AuthnzFcgiCheckAuthnProvider

+ + + + + + + + +
Description:Permet à une application FastCGI de gérer l'accroche +d'authentification check_authn.
Syntaxe:AuthnzFcgiCheckAuthnProvider provider-name|None +option ...
Défaut:none
Contexte:répertoire
AllowOverride:FileInfo
Statut:Extension
Module:mod_authnz_fcgi
+

Cette directive permet de confier à une application FastCGI la + gestion d'une phase spécifique du processus d'authentification ou + d'autorisation.

+ +

Certaines fonctionnalités des fournisseurs d'autorisation FastCGI + nécessitent cette directive en lieu et place de + AuthBasicProvider pour pouvoir être activées :

+ +
    +
  • L'authentification de type autre que basique ; en général, + détermination de l'identifiant utilisateur et renvoi de sa valeur + depuis le fournisseur d'autorisation ; voir l'option + UserExpr ci-dessous
    • +
  • Sélection d'un code de réponse personnalisé ; en cas de + code de réponse autre que 200 en provenance du fournisseur + d'autorisation, c'est ce code qui sera utilisé comme code d'état + de la réponse
    • +
  • Définition du corps d'une réponse autre que 200 ; si le + fournisseur d'autorisation renvoie un corps de réponse avec un + code autre que 200, c'est ce corps de réponse qui sera renvoyé au + client ; la longueur du texte est limitée à 8192 octets
    • +
+ +
+
provider-name
+
C'est le nom du fournisseur défini au préalable via la + directive AuthnzFcgiDefineProvider.
+ +
None
+
Spécifiez None pour désactiver un fournisseur + activé avec cette même directive dans une autre portée, par + exemple dans un répertoire parent.
+ +
option
+
Les options suivantes sont supportées : + +
+
Authoritative On|Off (par défaut On)
+
Cette option permet de définir si l'appel à d'autres + modules est autorisé lorsqu'un fournisseur d'autorisation FastCGI a + été configuré et si la requête échoue.
+ +
DefaultUser id utilisateur
+
Lorsque le fournisseur d'autorisation donne son accord, et + si UserExpr est défini et correspond à une chaîne + vide, (par exemple, si le fournisseur d'autorisation ne renvoie + aucune variable), c'est cette valeur qui sera utilisée comme id + utilisateur par défaut. Cela se produit souvent lorsqu'on se trouve dans + un contexte d'invité, ou d'utilisateur non authentifié ; + les utilisateurs et invités se voient alors attribué un id + utilisateur spécifique qui permettra de se connecter et + d'accéder à certaines ressources.
+ +
RequireBasicAuth On|Off (par défaut Off)
+
Cette option permet de définir si l'authentification + basique est requise avant de transmettre la requête au + fournisseur d'autorisation. Dans l'affirmative, le fournisseur + d'autorisation ne sera invoqué qu'en présence d'un id + utilisateur et d'un mot de passe ; si ces deux éléments ne sont + pas présents, un code d'erreur 401 sera renvoyé
+ +
UserExpr expr (pas de valeur par défaut)
+
Lorsque le client ne fournit pas l'authentification basique + et si le fournisseur d'autorisation détermine l'id utilisateur, + cette expression, évaluée après l'appel au fournisseur + d'autorisation, permet de déterminer l'id utilisateur. Cette + expression se conforme à la syntaxe + ap_expr et doit correspondre à une chaîne de caractères. + Une utilisation courante consiste à référencer la définition + d'une Variable-XXX renvoyée par le + fournisseur d'autorisation via une option du style + UserExpr "%{reqenv:XXX}". Si cette option + est spécifiée, et si l'id utilisateur ne peut pas être définie + via l'expression après une authentification réussie, la requête + sera rejetée avec un code d'erreur 500.
+ +
+
+
+ +
+
top
+

Directive AuthnzFcgiDefineProvider

+ + + + + + + +
Description:Définit une application FastCGI en tant que fournisseur +d'authentification et/ou autorisation
Syntaxe:AuthnzFcgiDefineProvider type provider-name +backend-address
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_authnz_fcgi
+

Cette directive permet de définir une application FastCGI en tant + que fournisseur pour une phase particulière d'authentification ou + d'autorisation.

+ +
+
type
+
Les valeurs de ce paramètre sont authn pour + l'authentification, authz pour l'autorisation, ou + authnz pour un fournisseur d'autorisation générique + FastCGI qui effectue les deux vérifications.
+ +
provider-name
+
Ce paramètre permet d'associer un nom au fournisseur ; ce nom + pourra être utilisé dans des directives comme AuthBasicProvider et + Require.
+ +
backend-address
+
Ce paramètre permet de spécifier l'adresse de l'application + sous la forme fcgi://hostname:port/. Le ou les processus + de l'application doivent être gérés indépendamment comme avec + fcgistarter.
+
+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_filter.html.fr b/docs/manual/mod/mod_filter.html.fr new file mode 100644 index 00000000000..fab4831fd37 --- /dev/null +++ b/docs/manual/mod/mod_filter.html.fr @@ -0,0 +1,568 @@ + + + + + +mod_filter - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+
+Apache > Serveur HTTP > Documentation > Version 2.5 > Modules
+
+

Module Apache mod_filter

+
+

Langues Disponibles:  en  | + fr 

+
+ + + +
Description:Module de configuration de filtre intelligent sensible au +contexte
Statut:Base
Identificateur de Module:filter_module
Fichier Source:mod_filter.c
+

Sommaire

+ +

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).

+
+ +
top
+
+

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.

+
top
+
+

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.

+
top
+
+

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.
+
+
top
+
+

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.

+
top
+
+

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.

+
top
+
+

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>
+ +
+
+
top
+
+

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.

+
+
top
+

Directive AddOutputFilterByType

+ + + + + + + + +
Description:assigne un filtre en sortie pour un type de média +particulier
Syntaxe:AddOutputFilterByType filtre[;filtre...] +type_de_média [type_de_média] ...
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
AllowOverride:FileInfo
Statut:Base
Module:mod_filter
Compatibilité: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>
+ + + +

Voir aussi

+ +
+
top
+

Directive FilterChain

+ + + + + + + +
Description:Configure la chaîne de filtrage
Syntaxe:FilterChain [+=-@!]nom_filtre ...
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
AllowOverride:Options
Statut:Base
Module:mod_filter
+

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
+
+ +
+
top
+

Directive FilterDeclare

+ + + + + + + +
Description:Déclare un filtre intelligent
Syntaxe:FilterDeclare nom_filtre [type]
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
AllowOverride:Options
Statut:Base
Module:mod_filter
+

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.

+ +
+
top
+

Directive FilterProtocol

+ + + + + + + +
Description:Vérifie le respect du protocole HTTP
Syntaxe:FilterProtocol nom_filtre [nom_fournisseur] + drapeaux_protocole
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
AllowOverride:Options
Statut:Base
Module:mod_filter
+

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)
+
+ +
+
top
+

Directive FilterProvider

+ + + + + + + +
Description:Enregistre un filtre de contenu
Syntaxe:FilterProvider nom_filtre nom_fournisseur + expression
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
AllowOverride:Options
Statut:Base
Module:mod_filter
+

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.

+ + +

Voir aussi

+ +
+
top
+

Directive FilterTrace

+ + + + + + +
Description:Obtention d'informations de débogage/diagnostique en +provenance de mod_filter
Syntaxe:FilterTrace nom_filtre niveau
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Base
Module:mod_filter
+

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é.
+
+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/module-dict.html.fr b/docs/manual/mod/module-dict.html.fr new file mode 100644 index 00000000000..757bdc500e7 --- /dev/null +++ b/docs/manual/mod/module-dict.html.fr @@ -0,0 +1,147 @@ + + + + + +Termes utilisés pour décrire les modules - Serveur Apache HTTP Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+
+Apache > Serveur HTTP > Documentation > Version 2.5

Termes utilisés pour décrire les modules

+
+

Langues Disponibles:  en  | + fr  | + ja  | + ko  | + tr 

+
+ +

Ce document décrit les termes utilisés pour décrire chaque module Apache.

+
+ +
top
+
+

Description

+ +

Une brève description des fonctions du module.

+
top
+
+

Statut

+ +

Ce terme indique le degré de rapprochement du module par rapport + au coeur du serveur web Apache ; en d'autres termes, vous pouvez + être amené à recompiler le serveur pour pouvoir accéder au module et + à ses fonctionnalités. Les valeurs possibles de cet attribut sont + :

+ +
+
MPM
+ +
Un module dont le statut est "MPM" est un module Multi-Processus. A la différence des + autres modules, un seul module MPM peut et doit être utilisé par Apache à + la fois. Ce type de module est responsable de la répartition et du + traitement de base des requêtes.
+ +
Base
+ +
Un module dont le statut est "Base" est compilé dans le + serveur et chargé avec ce dernier par défaut ; il est donc + toujours disponible à moins que vous n'ayez fait en sorte de + supprimer le module de votre configuration.
+ +
Extension
+ +
Un module dont le statut est "Extension" n'est pas compilé et + chargé dans le serveur par défaut. Pour activer le module et + accéder à ses fonctionnalités, vous devez modifier la + configuration de la compilation du serveur et recompiler + Apache.
+ +
Expérimental
+ +
Le statut "Experimental" indique que le module fait partie du + kit Apache, mais que vous devez l'utiliser à vos risques et + périls. Le module est documenté à des fins d'exhaustivité, et + n'est pas obligatoirement supporté.
+ +
Externe
+ +
Ce statut indique que le module ("module tiers") ne fait pas + partie de la distribution de base d'Apache. Nous ne sommes pas + responsables de ces modules et n'en assurons pas le support.
+
+
top
+
+

Fichier source

+ +

Il s'agit tout simplement de la liste des noms des fichiers + source qui contiennent le code du module. C'est aussi le nom utilisé + par la directive <IfModule>.

+
top
+
+

Identificateur de module

+ +

C'est une chaîne permettant d'identifier le module à utiliser + dans la directive LoadModule + pour le chargement dynamique des modules. En particulier, c'est le + nom de la variable externe de type module dans le fichier + source.

+
top
+
+

Compatibilité

+ +

Si le module ne faisait pas partie de la distribution originale + d'Apache version 2, la version à partir de laquelle il est + disponible est indiquée ici. En outre, si le module n'est disponible + que sur certaines plates-formes, cela sera mentionné ici.

+
+
+

Langues Disponibles:  en  | + fr  | + ja  | + ko  | + tr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file