From: Lucien Gentis Date: Thu, 14 May 2026 15:53:32 +0000 (+0000) Subject: fr doc XML files updates. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=ef0d4767b42ca9a88c0695314086d3d82f2596b5;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML files updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1934191 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_cache_socache.xml.fr b/docs/manual/mod/mod_cache_socache.xml.fr index b8430f2e0d..6e8a7f6197 100644 --- a/docs/manual/mod/mod_cache_socache.xml.fr +++ b/docs/manual/mod/mod_cache_socache.xml.fr @@ -1,7 +1,7 @@ - + @@ -164,11 +164,11 @@ cache Apache -

La directive CacheSocacheMaxSize - définit la taille maximale, en octets, de la somme des en-têtes et - du corps d'un document pouvant être stocké dans le cache. Bien - entendu, plus la taille des en-têtes sera grande, plus la taille - maximale du corps du document s'en trouvera réduite.

+

La directive CacheSocacheMaxSize définit la taille + maximale, en octets, de la somme des en-têtes et du corps d'un document + pouvant être stocké dans le cache. La valeur minimale est 1024 octets. Bien + entendu, plus la taille des en-têtes sera grande, plus la taille maximale du + corps du document s'en trouvera réduite.

Le module mod_cache_socache ne tentera de mettre en cache que des réponses qui possèdent une taille de contenu diff --git a/docs/manual/mod/mod_expires.xml.fr b/docs/manual/mod/mod_expires.xml.fr index 6e00fe70f9..60b3fb265c 100644 --- a/docs/manual/mod/mod_expires.xml.fr +++ b/docs/manual/mod/mod_expires.xml.fr @@ -1,7 +1,7 @@ - + @@ -49,9 +49,8 @@ l'utilisateur obtenue à partir du document source.

Pour modifier les directives de contrôle du cache autres - que max-age (voir la RFC - 2616 section 14.9), vous pouvez utiliser la directive max-age (voir la 2616, + section 14.9)), vous pouvez utiliser la directive Header.

Lorsque l'en-tête Expires est déjà présent dans la @@ -220,6 +219,24 @@ ExpiresByType text/html M604800

Vous pouvez aussi définir le mode de calcul de la date d'expiration en utilisant une syntaxe alternative, comme décrit plus haut dans ce document.

+ +

Le type MIME peut utiliser des caractères génériques pour le sous-type, + comme dans image/*. Cet exemple correspond à tout sous-type + sous le type principal. Lorsque le type de contenu d’une requête ne + correspond pas à une entrée ExpiresByType spécifique, + une entrée avec caractères génériques pour le type principal est recherchée + avant de se rebattre sur ExpiresDefault.

+ + Exemple avec caractères génériques :: + +ExpiresActive On +# Toutes les images sont périmées après 1 mois +ExpiresByType image/* "access plus 1 month" +# Override specifically for GIF +ExpiresByType image/gif "access plus 1 week" + + diff --git a/docs/manual/rewrite/index.xml.fr b/docs/manual/rewrite/index.xml.fr index 9634fe298a..464975685f 100644 --- a/docs/manual/rewrite/index.xml.fr +++ b/docs/manual/rewrite/index.xml.fr @@ -1,7 +1,7 @@ - + @@ -25,9 +25,17 @@ - Le module Apache mod_rewrite + Guide pour le module Apache mod_rewrite +

Le point fort de mod_rewrite réside dans le fait qu’il possède toutes les +capacités de configuration et la flexibilité de Sendmail ;mais c’est aussi son +point faible. +-- Brian Behlendorf

+ +

Malgré la multitude d'exemples et de documentations, mod_rewrite est de +la magie noire. De la magie noire très "cool", mais de la magie noire +quand-même.

mod_rewrite permet de modifier les requêtes entrantes dynamiquement, en fonction de règles manipulant des -

Il fournit un - mécanisme de manipulation d'URL particulièrement souple et - puissant en supportant un nombre illimité de règles et de - conditions attachées à chaque règle. Les manipulations d'URLs - peuvent dépendre de tests variés : les URLs peuvent - être finement caractérisées en fonction de variables du serveur, - de variables d'environnement, d'en-têtes HTTP, de repères - temporels, de recherches dans des bases de données - externes, ou même de requêtes vers des bases de données externes - et de différents gestionnaires ou programmes externes.

- -

Les règles de réécriture peuvent agir sur l'ensemble des URLs (la partie chemin - et la chaîne de paramètres) et peuvent être utilisées dans le contexte du serveur principal - (httpd.conf), mais aussi dans le contexte des - serveurs virtuels (sections VirtualHost), ou dans le - contexte des - répertoires (fichiers .htaccess et blocs - Directory). Le résultat - réécrit peut conduire vers d'autres règles à un - traitement secondaire interne, une redirection vers une requête - externe ou même l'envoi vers un serveur mandataire, en fonction - des drapeaux que vous attachez aux - règles

- -

mod_rewrite étant très puissant, il peut par - conséquent être très complexe. Ce document - complète la documentation de - référence du module mod_rewrite, et est sensé alléger un - peu cette complexité, et présenter des exemples largement - commentés, ainsi que des situations courantes que vous - pourrez traiter avec mod_rewrite. Mais nous voulons aussi vous - montrer des situations où vous ne devrez pas utiliser - mod_rewrite, et lui préférer d'autres - fonctionnalités standard d'Apache, évitant ainsi - d'entrer dans une complexité inutile.

- - +

Ce guide est un complément du manuel de +référence avec des exemples commentés, des explications conceptuelles et des +conseils pratiques. Il est organisé comme suit :

+ +
+
Introduction
+
Concepts de base : syntaxe des expressions rationnelles, les bases des +directives RewriteRule et RewriteCond et la manière dont mod_rewrite s’insère +dans le cycle de vie du traitement des requêtes.
+ +
Réécritures en fonction du répertoire
+
Les principales différences entre l’utilisation des règles de réécriture au +niveau de la configuration globale du serveur et leur utilisation dans un +contexte de répertoire, y compris la +suppression du chemin, RewriteBase et la gestion du bouclage par le drapeau [L].
+ +
Drapeaux des règles de réécriture
+
Une référence complète de tous les drapeaux qui peuvent modifier le +comportement d’une règle de réécriture avec des exemples pour chacun d’entre +eux.
+ +
Utiliser RewriteMap
+
Comment utiliser des sources de recherche externes — fichiers texte, +bases de données DBM, requêtes SQL et fonctions internes — pour piloter +vos règles de réécriture.
+ +
Redirection et remappage
+
Des recettes pour les tâches courantes : redirection HTTPS, noms d’hôte +canoniques, normalisation des barres obliques de fin, routage du contrôleur +frontal, et plus encore.
+ +
Serveurs virtuels dynamiques
+
Utilisation de mod_rewrite pour associer dynamiquement les noms d’hôte aux +racines de document sans devoir créer des blocs VirtualHost individuels.
+ +
Quand ne pas utiliser mod_rewrite
+
De nombreuses tâches courantes sont accomplies de manière bien plus efficace +avec des directives plus simples. Ce document vous propose des solutions de +remplacement et vous indique quand il est préférable de les utiliser.
+ +
Détails techniques
+
Comment mod_rewrite s’insère dans les phases de traitement des requêtes par +httpd et l’ordre dans lequel les règles et les conditions sont évaluées.
+
 Documentation de diff --git a/docs/manual/rewrite/tech.xml.fr b/docs/manual/rewrite/tech.xml.fr index fe2bd192fe..5f6431bb1a 100644 --- a/docs/manual/rewrite/tech.xml.fr +++ b/docs/manual/rewrite/tech.xml.fr @@ -1,7 +1,7 @@ - + @@ -35,11 +35,10 @@ module mod_rewrite et de la mise en correspondance des URLs

Introduction à mod_rewrite Redirection et remise en correspondance -Contrôle d'accès +Drapeaux de réécriture Serveurs virtuels -Mise en cache Utilisation de RewriteMap -Techniques avancées +Réécritures en fonction du répertoire Quand ne pas utiliser mod_rewrite
Phases de l'API @@ -82,68 +81,13 @@ correspondance REQUEST_URI soit vers une nouvelle URL, soit vers un nom de fichier.

-

Dans un contexte de niveau répertoire (autrement dit dans les - fichiers .htaccess et les sections - Directory), les règles de réécriture s'appliquent après - la traduction de l'URL en nom de fichier. C'est pourquoi le chemin - URL auquel mod_rewrite compare initialement les directives - RewriteRule est le - chemin complet vers le nom de fichier traduit amputé de la partie - répertoires (y compris le dernier slash).

- -

Un exemple : si les règles se trouvent dans - /var/www/foo/.htaccess et si une requête pour /foo/bar/baz est - traité, une expression comme ^bar/baz$ correspondra.

- -

Si une substitution intervient dans un contexte de répertoire, - une nouvelle sous-requête interne est générée avec la nouvelle URL, - ce qui relance le traitement des phases de la requête. Si la - substitution est un chemin relatif, la directive RewriteBase détermine le chemin URL - devant préfixer cette substitution. Dans un contexte de répertoire, - il faut s'assurer de créer des règles qui - n'effectueront pas de substitution au - cours d'une passe ultérieure du processus de réécriture au niveau - répertoire afin d'éviter les bouclages . Voir Bouclage dans le - processus de réécriture pour une discussion plus détaillée à - propos de ce problème.

- -

En conséquence de cette manipulation de l'URL , vous devrez - pensez à confectionner différemment vos règles de réécriture dans un - contexte de niveau répertoire. En particulier, rappelez-vous que le - chemin de répertoire sera absent de l'URL que vos règles de - réécriture verront. Voici quelques exemples qui permettront de - clarifier les choses :

- - - - - - - - - - - - - - - - - - - - - - - -
Position de la règleRègle
Section VirtualHostRewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
Fichier .htaccess à la racine des documentsRewriteRule "^images/(.+)\.jpg" "images/$1.gif"
Fichier .htaccess dans le répertoire imagesRewriteRule "^(.+)\.jpg" "$1.gif"
- -

Pour une étude plus approfondie de la manière dont mod_rewrite - manipule les URLs dans les différents contextes, vous pouvez - consulter les entrées du - journal générées au cours du processus de réécriture.

+

Dans un contexte de répertoire, + les règles sont appliquées durant la phase "Fixup" après que l’URL a été + traduite en nom de fichier. Cela modifie ce à quoi correspond le motif et la + manière dont les substitutions sont gérées. Voir le document Réécritures en fonction du + répertoire pour des détails pratiques à propos de la suppression du + chemin, de RewriteBase et de la manière d’éviter un bouclage.