From: Rich Bowen Date: Mon, 2 Jan 2012 22:52:11 +0000 (+0000) Subject: s/2011/2012/g X-Git-Tag: 2.5.0-alpha~7609 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5d3d7c8875fa5e9ccc6ada1c1d7602a9cd28a420;p=thirdparty%2Fapache%2Fhttpd.git s/2011/2012/g git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1226563 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/bind.html.de b/docs/manual/bind.html.de index 387a2998ecb..03e261ad21d 100644 --- a/docs/manual/bind.html.de +++ b/docs/manual/bind.html.de @@ -168,6 +168,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/bind.html.en b/docs/manual/bind.html.en index 6414cf3fe0f..ec7b06446d5 100644 --- a/docs/manual/bind.html.en +++ b/docs/manual/bind.html.en @@ -187,6 +187,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/bind.html.fr b/docs/manual/bind.html.fr index 99e41f343ed..bf9c613518d 100644 --- a/docs/manual/bind.html.fr +++ b/docs/manual/bind.html.fr @@ -196,6 +196,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/bind.html.ja.utf8 b/docs/manual/bind.html.ja.utf8 index 85d98927c3c..38be03282f4 100644 --- a/docs/manual/bind.html.ja.utf8 +++ b/docs/manual/bind.html.ja.utf8 @@ -177,6 +177,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/bind.html.ko.euc-kr b/docs/manual/bind.html.ko.euc-kr index 26f7b2b0717..ad7db2ddd3c 100644 --- a/docs/manual/bind.html.ko.euc-kr +++ b/docs/manual/bind.html.ko.euc-kr @@ -148,6 +148,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/bind.html.tr.utf8 b/docs/manual/bind.html.tr.utf8 index e0ad98dcc7b..cfae5bf063a 100644 --- a/docs/manual/bind.html.tr.utf8 +++ b/docs/manual/bind.html.tr.utf8 @@ -184,6 +184,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/caching.html.en b/docs/manual/caching.html.en index f9ccfffe3ec..71f3c0a2f9b 100644 --- a/docs/manual/caching.html.en +++ b/docs/manual/caching.html.en @@ -831,6 +831,6 @@ sys 0m0.000s  fr  |  tr 

\ No newline at end of file diff --git a/docs/manual/caching.html.fr b/docs/manual/caching.html.fr index 5a3cde048cf..c6c0a6c07fc 100644 --- a/docs/manual/caching.html.fr +++ b/docs/manual/caching.html.fr @@ -32,55 +32,60 @@ courants et les erreurs de configuration.

top

Introduction

-

Depuis la version 2.2 du serveur HTTP Apache, les modules - mod_cache - et mod_file_cache ne sont plus jugés expérimentaux - et on considère qu'ils peuvent être utilisés en production. Ces - architectures de mise en cache constituent un puissant concept - d'accélération de la gestion HTTP, tant comme serveur web originel - que comme mandataire.

- -

Le module mod_cache et son module de soutien - mod_cache_disk - permettent une mise en cache intelligente du point de vue HTTP. - Le contenu proprement dit est stocké dans le cache, - et mod_cache tente d'honorer tous les en-têtes HTTP et les options - qui définissent la possibilité de mise en cache du contenu. Il gère non - seulement le contenu local, mais aussi le contenu mandaté. - mod_cache - est conçu pour des configurations de mise en cache simples ou complexes, - dans lesquels vous traitez de contenu mandaté, de contenu local dynamique - ou avez besoin d'accélérer l'accès à des fichiers locaux qui sont modifiés - au cours du temps.

- -

Le module mod_file_cache quant à lui, constitue une - forme de mise en cache plus basique, mais quelques fois intéressante. - Plutôt que de gérer la complexité de s'assurer de manière active de la - possibilité de mise en cache d'URLs, - mod_file_cache fournit des méthodes pour la gestion - et l'édition de fichiers en mémoire afin de maintenir un cache de fichiers - dans l'état où ils étaient la dernière - fois qu'httpd a démarré. - En tant que tel, mod_file_cache a été conçu pour améliorer - le temps d'accès à des fichiers locaux statiques qui ne sont modifiés - que rarement.

- -

Etant donné que mod_file_cache constitue une - implémentation de mise en cache relativement simple, mises à part les - sections spécifiques sur les directives CacheFile et MMapFile, les explications fournies - dans ce guide concernent l'architecture de mise en cache du - module mod_cache.

+

Le serveur HTTP Apache offre tout un ensemble de fonctionnalités + de mise en cache qui ont été conçues pour améliorer les performances + du serveur de différentes manières.

+ +
+
Mise en cache HTTP à trois états RFC2616
+
mod_cache et son module de fournisseur + mod_cache_disk proposent une mise en cache + intelligente de niveau HTTP. Le contenu proprement dit est + stocké dans le cache, et mod_cache vise à respecter tous les + en-têtes HTTP, ainsi que les options qui contrôlent la mise en + cache du contenu comme décrit dans la Section + 13 de la RFC2616. mod_cache peut gérer des + configurations de mise en cache simples, mais aussi complexes + comme dans les cas où vous avez à faire à des contenus mandatés, + à des contenus locaux dynamiques, ou lorsque vous avez besoin + d'accélérer l'accès aux fichiers locaux situés sur disque + supposé lent. +
+ +
Mise en cache d'objets partagés de forme clé/valeur à deux + états
+
+ mod_socache et ses modules de fournisseurs + proposent une mise en cache d'objets partagés à base de + couples clé/valeur de niveau serveur. Ces modules sont + conçus pour la mise en cache de données de bas niveau comme + les sessions SSL et les données d'authentification. les + serveurs d'arrière-plan permettent le stockage des données + au niveau serveur en mémoire partagée, ou au niveau + datacenter dans un cache comme memcache ou distcache. +
+ +
Mise en cache de fichiers spécialisée
+
+ mod_file_cache offre la possibilité de + précharger des fichiers en mémoire au démarrage du serveur, + et peut améliorer les temps d'accès et sauvegarder les + gestionnaires de fichiers pour les fichiers qui font l'objet + d'accès fréquents, évitant ainsi d'avoir à accéder au disque + à chaque requête. +
+

Pour tirer parti efficacement de ce document, les bases de HTTP doivent vous être familières, et vous devez avoir lu les sections @@ -91,96 +96,184 @@

top
-

Vue d'ensemble de la mise en cache

+

Mise en cache HTTP à trois états RFC2616

-
Modules ApparentésDirectives Apparentées
- -

mod_cache peut faire intervenir deux phases - principales pendant la durée de vie d'une requête. - En premier lieu, mod_cache - est un module de mise en correspondance d'URLs, ce qui signifie que si - une URL a été mise en cache, et que la version du cache de cette URL n'est - pas arrivée à expiration, la requête sera traitée directement par - mod_cache.

- -

Ceci entraîne que toutes autres actions qui se dérouleraient normalement - au cours du processus de traitement d'une requête -- par exemple un - traitement effectué par mod_proxy, ou - mod_rewrite -- - ne seront pas effectuées. Mais c'est justement l'intérêt - de la mise en cache préalable du contenu.

- -

Si l'URL ne se trouve pas dans le cache, mod_cache - va ajouter un filtre au traitement de la requête. - Une fois le contenu localisé par httpd selon la conception courante, le - filtre sera exécuté en même temps que le contenu sera servi. - S'il est déterminé que le contenu peut être mis en cache, - il sera sauvegardé dans le cache pour une utilisation future.

- -

Si l'URL se trouve dans le cache, mais est arrivée à expiration, - le filtre est quand-même ajouté, mais mod_cache va créer - une requête conditionnelle en arrière-plan, pour déterminer si la version - du cache est encore à jour. Si la version du cache est encore à jour, ses - meta-informations seront mises à jour et la requête sera servie à partir du - cache. Si la version du contenu n'est plus à jour, elle sera supprimée et le - filtre va sauvegarder le contenu mis à jour dans le cache - au moment où il sera servi.

+
Modules ApparentésDirectives Apparentées
+ +

Le module mod_cache permet de tirer avantage du + mécanisme de mise en cache en ligne faisant partie + intégrante du protocole HTTP, et décrit dans la section + 13 de la RFC2616.

+ +

A la différence d'un cache simple clé/valeur à deux états où le + contenu est supprimé lorsqu'il est périmé, un cache HTTP comporte un + mécanisme permettant de conserver temporairement un contenu périmé, + de demander au serveur original si ce contenu périmé a été modifié, + et dans le cas contraire de le rendre à nouveau valide.

+ +

Une entrée d'un cache HTTP peut se présenter sous un de ces trois + états :

+ +
+
Frais
+
+ Si un contenu est suffisamment récent (plus jeune que sa + durée de fraîcheur), il est considéré comme + frais. Un cache HTTP peut servir un contenu + frais sans avoir à demander quoi que ce soit au serveur + d'origine. +
+
Périmé
+
+

Si le contenu est trop ancien (plus vieux que sa + durée de fraîcheur), il est considéré comme + périmé. Un cache HTTP doit contacter le serveur + original pour vérifier si le contenu, même s'il est périmé, est + encore à jour avant de le servir au client. Soit le serveur + original va répondre en envoyant un contenu de remplacement si + le contenu périmé n'est plus à jour, soit dans le cas idéal il + renverra un code pour signaler au cache que le contenu est + encore à jour, et qu'il est inutile de le générer ou de + l'envoyer à nouveau. Le contenu repasse à l'état "frais" et le + cycle continue.

+ +

Le protocole HTTP permet au cache de servir des données + périmées dans certaines circonstances, comme lorsqu'une + tentative de rafraîchir une entrée depuis un serveur original + se solde par un échec avec un code d'erreur 5xx, ou lorsqu'une + autre requête est déjà en train d'essayer de rafraîchir la même + entrée. Dans ces cas, un en-tête Warning est ajouté + à la réponse.

+
+
Non Existent
+
+ Si le cache est plein, il se réserve la possibilité de supprimer + des entrées pour faire de la place. Une entrée peut être + supprimée à tout moment, qu'elle soit fraîche ou périmée. + L'outil htcacheclean + peut être utilisé à la demande, ou lancé en tant que démon afin + de conserver la taille du cache ou le nombre d'inodes en deçà de + valeurs spécifiées. Cet outil essaie cependant de + supprimer les entrées périmées avant les entrées fraîches. +
+
+ +

Le fonctionnement détaillé d'un cache HTTP est décrit dans la Section + 13 de la RFC2616.

+ +

Interaction avec le serveur

+ + +

Le module mod_cache interagit avec le serveur + à deux niveaux possibles en fonction de la directive CacheQuickHandler : +

+ +
+
Phase du gestionnaire rapide
+
+

Cette phase se déroule très tôt au cours du traitement de + la requête, juste après l'interprétation de cette dernière. Si + le contenu se trouve dans le cache, il est servi immédiatement + et pratiquement tout le reste du traitement de la requête est + court-circuité.

+ +

Dans ce scénario, le cache se comporte comme s'il avait + été "boulonné" à l'entrée du serveur.

+ +

Ce mode possède les meilleures performances car la + majorité des traitements au niveau du serveur sont + court-circuités. Cependant, il court-circuite aussi les + phases d'authentification et d'autorisation du traitement + au niveau du serveur, et il doit donc être utilisé avec + prudence lorsque que ces phases sont importantes.

+
+
Phase du gestionnaire normal
+
+

Cette phase se déroule très tard au cours du traitement + de la requête, en fait après toutes les phases de ce + traitement.

+ +

Dans ce scénario, le cache se comporte comme s'il avait + été "boulonné" à la sortie du serveur.

+ +

Ce mode offre la plus grande souplesse, car il permet + de faire intervenir la mise en cache en un point + précisément spécifié de la chaîne de filtrage, et le + contenu issu du cache peut être filtré ou personnalisé + avant d'être servi au client.

+
+
+ +

Si l'URL ne se trouve pas dans le cache, + mod_cache ajoutera un filtre à la chaîne de filtrage afin + d'enregistrer la réponse dans le cache, puis passera la main + pour permettre le déroulement normal de la suite du traitement + de la requête. Si la mise en cache du contenu est autorisée, il + sera enregistré dans le cache pour pouvoir être servi à nouveau + ; dans le cas contraire, le contenu sera ignoré.

+ +

Si le contenu trouvé dans le cache est périmé, le module + mod_cache convertit la requête en + requête conditionnelle. Si le serveur original + renvoie une réponse normale, elle est enregistrée dans le cache + en lieu et place du contenu périmé. Si le serveur original + renvoie une réponse "304 Not Modified", le contenu repasse à + l'état "frais" et est servi par le filtre au lieu d'être + sauvegardé.

+

Amélioration du taux de présence dans le cache

-

Lors de la mise en cache de contenu généré localement, le - positionnement de la directive +

Lorsqu'un serveur virtuel est connu sous la forme d'un des + nombreux alias du serveur, la définition de la directive UseCanonicalName à - On peut améliorer de manière spectaculaire le taux de - présence dans le cache. Ceci est du au fait que le nom d'hôte de l'hôte - virtuel qui sert le contenu constitue une partie de la clé de cache. + On peut augmenter de manière significative le nombre + de correspondances positives dans le cache. Ceci est du au fait + que la clé du cache contient le nom d'hôte du serveur virtuel. Avec UseCanonicalName positionnée à On, les hôtes virtuels possédant plusieurs noms de serveur ou alias ne généreront pas d'entités de cache différentes, et le contenu sera mis en cache en faisant référence au nom d'hôte canonique.

-

Les documents mis en cache ne seront servis qu'en réponse à des - requêtes de type URL, car la mise en cache est effectuée lors de la phase - de traduction de l'URL en nom de fichier. - En général, cela n'a que peu d'effet, à moins que vous n'utilisiez les - Inclusions Côté Serveur (SSI);

- -

-<!-- L'inclusion suivante peut être mise en cache -->
-<!--#include virtual="/footer.html" -->
-
-<!-- L'inclusion suivante ne peut pas être mise en cache -->
-<!--#include file="/path/to/footer.html" -->
-

- -

Si vous utilisez les SSI, et voulez bénéficier de la vitesse de - service depuis le cache, vous devez utiliser des inclusions de type - virtual.

-

Périodes d'expiration

+

Durée de fraîcheur

-

La période d'expiration par défaut pour les entités du cache est - d'une heure; elle peut cependant être facilement modifiée à l'aide de - la directive CacheDefaultExpire. Cette valeur par - défaut n'est utilisée que lorsque la source originale du contenu ne - précise pas de période d'expiration ou d'heure de dernière - modification.

+

Un contenu bien formé destiné à être mis en cache doit déclarer + explicitement une durée de fraîcheur via les champs + max-age ou s-maxage de l'en-tête + Cache-Control, ou en incluant un en-tête + Expires.

+ +

De plus, un client peut passer outre la durée de fraîcheur + définie pour le serveur original en ajoutant son propre en-tête + Cache-Control à la requête. Dans ce cas, c'est la + durée de fraîcheur la plus basse entre la requête et la réponse + qui l'emporte.

+ +

Lorsque cette durée de fraîcheur est absente de la requête ou + de la réponse, une durée de fraîcheur par défaut s'applique. La + durée de fraîcheur par défaut des entrées du cache est d'une heure + ; elle peut cependant être facilement modifiée à l'aide de + la directive CacheDefaultExpire.

Si une réponse ne contient pas d'en-tête Expires mais inclut un en-tête Last-Modified, mod_cache - peut déduire une période d'expiration en se basant sur la valeur de la - directive CacheLastModifiedFactor.

+ peut déduire une durée de fraîcheur en se basant sur une + heuristique, qui peut être contrôlée via la directive CacheLastModifiedFactor.

-

La période d'expiration des contenus locaux peut être ajustée finement - en utilisant le module mod_expires.

+

Pour les contenus locaux, ou les contenus distants qui ne + spécifient pas leur propre en-tête Expires, + mod_expires permet de régler finement la durée de + fraîcheur via les paramètres max-age et + Expires.

-

On peut aussi contrôler la période d'expiration maximale en utilisant +

On peut aussi contrôler la durée de fraîcheur maximale en utilisant la directive CacheMaxExpire.

@@ -188,64 +281,61 @@

Guide succinct des requêtes conditionnelles

-

Lorsqu'un contenu est arrivé à expiration dans le cache et fait - l'objet d'une nouvelle demande d'accès, plutôt que traiter directement - la requête originale, httpd préfère utiliser une - requête conditionnelle.

- -

HTTP propose toute une panoplie d'en-têtes qui permettent à un client, - ou au cache de distinguer les différentes versions d'un même contenu. Par - exemple, si une ressource a été servie avec un en-tête "Etag:", il est - possible de créer une requête conditionnelle contenant un en-tête - "If-None-Match:". Si une ressource a été servie avec un en-tête - "Last-Modified:", il est possible de créer une requête conditionnelle - contenant un en-tête "If-Modified-Since:", etc....

- -

Lorsqu'une telle requête conditionnelle est créée, la reponse diffère - selon que le contenu satisfait ou non aux conditions. Si une requête est - créée avec un en-tête "If-Modified-Since:", et le contenu n'a pas été - modifié depuis le moment indiqué dans la requête, alors un laconique - "304 Not Modified" est retourné.

- -

Si le contenu a été modifié, il est servi comme si la requête n'avait - pas été conditionnelle à l'origine.

- -

Les bénéfices des requêtes conditionnelles pour ce qui concerne la - mise en cache sont de deux sortes. Premièrement, quand une telle requête - est envoyée au processus en arrière-plan, il sera aisé de déterminer - si le contenu que devra servir le processus en arrière-plan correspond - au contenu stocké dans le cache, sans être obligé de transmettre la - totalité de la ressource.

- -

Deuxièmement, les requêtes conditionnelles sont en général moins - coûteuses en ressources pour le processus en arrière-plan. - Pour ce qui est des fichiers - statiques, l'action type est un appel à stat() ou un appel - système similaire, pour déterminer si la taille du fichier ou sa date de - modification ont changé. Ainsi, même si httpd met en cache le contenu - local, un contenu arrivé à expiration pourra être servi plus rapidement - depuis le cache s'il n'a pas été modifié, parce que la lecture depuis le - cache est plus rapide que la lecture depuis le processus en arrière-plan - (à comparer à la différence de vitesse entre la lecture depuis un cache en - mémoire avec mod_cache_disk et la lecture depuis un disque).

+

Lorsqu'un contenu du cache est périmé, httpd modifie la requête + pour en faire une requête conditionnelle

+ +

Lorsque la réponse originale du cache contient un en-tête + ETag, mod_cache ajoute un en-tête + If-None-Match à la requête envoyée au serveur + d'origine. Lorsque la réponse originale du cache contient un en-tête + Last-Modified, mod_cache ajoute un en-tête + If-Modified-Since à la requête envoyée au serveur + d'origine. Dans ces deux cas, la requête devient une requête + conditionnelle.

+ +

Lorsqu'un serveur d'origine reçoit une requête conditionnelle, + il vérifie si le paramètre Etag ou Last-Modified a été modifié en + fonction des paramètres de la requête. Si ce n'est pas le cas, il + répondra avec le message lapidaire "304 Not Modified". Ceci + informe le cache que le contenu est périmé mais encore à jour, et + peut être utilisé tel quel pour les prochaines requêtes jusqu'à ce + qu'il atteigne à nouveau sa date de péremption.

+ +

Si le contenu a été modifié, il est servi comme s'il s'agissait + d'une requête normale et non conditionnelle.

+ +

Les requêtes conditionnelles offrent deux avantages. D'une + part, il est facile de déterminer si le contenu du serveur + d'origine correspond à celui situé + dans le cache, et ainsi d'économiser la consommation de ressources + nécessaire au transfert du contenu dans son ensemble.

+ +

D'autre part, un serveur d'origine bien conçu sera configuré de + telle manière que les requêtes conditionnelles nécessitent pour + leur production bien moins de ressources qu'une réponse complète. + Dans le cas des fichiers statiques, il suffit en général d'un + appel système de type stat() ou similaire pour + déterminer si la taille ou la date de modification du fichier a + été modifiée. Ainsi, même un contenu local pourra être servi plus + rapidement depuis le cache s'il n'a pas été modifié.

+ +

Il serait souhaitable que tous les serveurs d'origine + supportent les requêtes conditionnelles, car dans le cas + contraire, ils répondent comme s'il s'agissait d'une requête + normale, et le cache répond comme si le contenu avait été + modifié et enregistre ce dernier. Le cache se comporte alors + comme un simple cache à deux état, où le contenu est servi s'il + est à jour, ou supprimé dans le cas contraire.

Que peut-on mettre en cache ?

-

Comme mentionné plus haut, les deux styles de mise en - cache de httpd - fonctionnent différemment; la mise en cache de - mod_file_cache conserve les contenus des fichiers - tels qu'ils étaient au démarrage de httpd. Quand une requête pour un - fichier mis en cache par ce module est envoyée, elle est interceptée - et le fichier mis en cache est servi.

- -

La mise en cache de mod_cache, quant à elle, est - plus complexe. Lors du traitement d'une requête, le module de mise en - cache déterminera si le contenu peut être mis en cache, s'il ne l'a - pas déjà été auparavant. Les conditions qui permettent de déterminer - la possibilité de mise en cache d'une réponse sont :

+

La liste complète des conditions nécessaires pour qu'une + réponse puisse être enregistrée dans un cache HTTP est fournie + dans la section + 13.4 Response Cacheability de la RFC2616, et peut se résumer + ainsi :

  1. La mise en cache doit être activée pour cette URL. Voir les @@ -256,9 +346,6 @@
  2. La requête doit être de type HTTP GET.
    3. -
  3. Si la requête contient un en-tête "Authorization:", la réponse ne - sera pas mise en cache.
    4. -
  4. Si la réponse contient un en-tête "Authorization:", elle doit aussi contenir une option "s-maxage", "must-revalidate" ou "public" dans l'en-tête "Cache-Control:".
    5. @@ -299,28 +386,46 @@

    Qu'est ce qui ne doit pas être mis en cache ?

    -

    En bref, tout contenu qui varie beaucoup avec le temps, ou en fonction - de particularités de la requête qui ne sont pas couvertes par la - négociation HTTP, ne doit pas être mis en cache.

    - -

    Un contenu dynamique qui varie en fonction de l'adresse IP du - demandeur, ou est modifié toutes les 5 minutes, ne devra en général - pas être mis en cache.

    +

    Le client qui crée la requête ou le serveur d'origine qui + génère la réponse doit être à même de déterminer si le contenu + doit pouvoir être mis en cache ou non en définissant correctement + l'en-tête Cache-Control, et + mod_cache sera alors en mesure de satisfaire les + souhaits du client ou du serveur de manière appropriée. +

    -

    Si par contre le contenu servi diffère en fonction de la valeur de - divers en-têtes HTTP, il se peut que l'on puisse le mettre en cache - intelligemment en utilisant un en-tête "Vary".

    +

    Les contenus qui varient au cours du temps, ou en fonction de + particularités de la requête non prises en compte par la + négociation HTTP ne doivent pas être mis en cache. Ce type de + contenu doit se déclarer lui-même "à ne pas mettre en cache" via + l'en-tête Cache-Control.

    + +

    Si le contenu change souvent, suite par exemple à une durée de + fraîcheur de l'ordre de la minute ou de la seconde, il peut tout + de même être mis en cache, mais il est alors fortement souhaitable + que le serveur d'origine supporte correctement les + requêtes conditionnelles afin que des réponses + complètes ne soient pas systématiquement générées.

    + +

    Un contenu qui varie en fonction d'en-têtes de requête fournis + par le client peut être mis en cache, sous réserve d'une + utilisation appropriée de l'en-tête de réponse Vary.

    Contenu variable et/ou négocié

    -

    Si mod_cache reçoit une réponse contenant un en-tête - "Vary", lorsqu'un contenu a été demandé par un processus d'arrière-plan, - il va s'efforcer de la traiter intelligemment. Si possible, - mod_cache va détecter les en-têtes attribués dans la - réponse "Vary" à l'occasion des futures demandes, et servir une réponse - correcte à partir du cache.

    +

    Lorsque le serveur d'origine est configuré pour servir des + contenus différents en fonction de la valeur de certains en-têtes + de la requête, par exemple pour servir une ressource en plusieurs + langages à partir d'une seule URL, le mécanisme de mise en cache + d'HTTP permet de mettre en cache plusieurs variantes de la même + page à partir d'une seule URL.

    + +

    Pour y parvenir, le serveur d'origine ajoute un en-tête + Vary pour indiquer quels en-têtes doivent être pris + en compte par un cache pour déterminer si deux variantes sont + différentes l'une de l'autre.

    Si par exemple, une réponse est reçue avec l'en-tête Vary suivant,

    @@ -331,171 +436,265 @@ Vary: negotiate,accept-language,accept-charset

    mod_cache ne servira aux demandeurs que le contenu mis en cache qui correspond au contenu des en-têtes accept-language et accept-charset de la requête originale.

    - -
top
-
-

Considérations sur la sécurité

+

Plusieurs variantes d'un contenu peuvent être mises en cache + simultanément ; mod_cache utilise l'en-tête + Vary et les valeurs correspondantes des en-têtes de + la requête spécifiés dans ce dernier pour + déterminer quelle variante doit être servie au client.

+ -

Autorisation et contrôle d'accès

+

Mise en cache sur disque

-

Utiliser mod_cache revient sensiblement à la même - chose qu'avoir un mandataire inverse intégré (reverse-proxy). Les requêtes - seront servies par le module de mise en cache sauf si ce dernier - détermine qu'un processus d'arrière-plan doit être appelé. La mise en - cache de ressources locales modifie considérablement le modèle de - sécurité de httpd.

+

Le module mod_cache s'appuie sur des + implémentations de stockage en arrière-plan spécifiques pour gérer + le cache ; à ce titre, mod_cache_disk fournit le + support de la mise en cache sur disque.

-

Comme le parcours de la hiérarchie d'un système de fichiers pour - examiner le contenu d'éventuels fichiers - .htaccess serait une opération très coûteuse en ressources, - annulant partiellement de ce fait l'intérêt de la mise en cache - (accélérer le traitement des requêtes), - mod_cache ne se préoccupe pas de savoir s'il a - l'autorisation de servir une entité mise en cache. En d'autres termes, - si mod_cache a mis en cache un certain contenu, ce - dernier sera servi à partir du cache tant qu'il ne sera pas arrivé à - expiration.

+

En général, le module se configure comme suit :

+ +

+CacheRoot /var/cache/apache/
+CacheEnable disk /
+CacheDirLevels 2
+CacheDirLength 1 +

+ +

Il est important de savoir que, les fichiers mis en cache étant stockés + localement, la mise en cache par l'intermédiaire du système d'exploitation + sera en général aussi appliquée à leurs accès. Si bien que même si les + fichiers sont stockés sur disque, s'il font l'objet d'accès fréquents, + il est probable que le système d'exploitation s'appliquera à ce qu'ils + soient servis à partir de la mémoire.

-

Si par exemple, votre configuration autorise l'accès à une ressource - en fonction de l'adresse IP, vous devez vous assurer que ce contenu n'est - pas mis en cache. Ceci est possible en utilisant la directive - CacheDisable, ou le module - mod_expires. Livré à lui-même, - mod_cache - pratiquement comme un mandataire inverse - - mettrait en cache le contenu lors de son service, et le servirait ensuite - à tout client, vers n'importe quelle adresse IP.

-

Piratages locaux

+

Comprendre le stockage dans le cache

-

Etant donné que les requêtes des utilisateurs finaux peuvent être - servies depuis le cache, ce dernier est une cible potentielle pour ceux - qui veulent défigurer un contenu ou interférer avec lui. Il est important - de garder à l'esprit que l'utilisateur sous lequel tourne - httpd doit - toujours avoir l'accès en écriture dans le cache. Ceci est en contraste - total avec la recommandation usuelle d'interdire à l'utilisateur sous - lequel tourne Apache - l'accès en écriture à tout contenu.

+

Pour stocker des entités dans le cache, + le module mod_cache_disk crée une empreinte (hash) de 22 + caractères de l'URL qui a fait l'objet d'une requête. Cette empreinte + comprend le nom d'hôte, le protocole, le port, le chemin et tout argument + de type CGI associé à l'URL, ainsi que les éléments + spécifiés dans l'en-tête Vary afin d'être sur que plusieurs URLs + n'interfèrent pas entre elles.

-

Si l'utilisateur sous lequel tourne Apache est compromis, - par exemple à cause d'une - faille de sécurité dans un processus CGI, il est possible que le cache - fasse l'objet d'une attaque. Il est relativement aisé d'insérer ou de - modifier une entité dans le cache en utilisant le module - mod_cache_disk.

+

Chaque position de l'empreinte peut contenir un caractère + choisi parmi 64 caractères différents, il y a donc + 64^22 possibilités pour une empreinte. Par exemple, une URL peut posséder + l'empreinte xyTGxSMO2b68mBCykqkp1w. Cette empreinte est + utilisée pour préfixer les noms de fichiers spécifiques à cette URL à + l'intérieur du cache; cependant, elle est tout d'abord placée dans les + répertoires du cache selon les directives + CacheDirLevels et + CacheDirLength.

-

Cela représente un risque relativement élévé par rapport aux autres - types d'attaques qu'il est possible de mener sous l'utilisateur apache. - Si vous utilisez mod_cache_disk, vous devez garder ceci - à l'esprit : effectuez toujours les mises à jour de - httpdquand des - correctifs de sécurité sont annoncés et exécutez les processus CGI sous - un utilisateur autre qu'apache en utilisant - suEXEC dans la mesure du possible.

+

La directive + CacheDirLevels + définit le nombre de niveaux de sous-répertoires, et + CacheDirLength + le nombre de caractères composant le nom des sous-répertoires. Dans + l'exemple donné plus haut, l'empreinte se trouvera à : + /var/cache/apache/x/y/TGxSMO2b68mBCykqkp1w.

+ +

Cette technique a pour but principal de réduire le nombre de + sous-répertoires ou de fichiers contenus dans un répertoire particulier, + car le fonctionnement de la plupart des systèmes de fichiers est ralenti + quand ce nombre augmente. Avec la valeur "1" pour la directive + CacheDirLength, + il peut y avoir au plus 64 sous-répertoires à un niveau quelconque. + Avec la valeur "2", il peut y en avoir 64 * 64, etc... + A moins d'avoir une bonne raison pour ne pas le faire, l'utilisation de + la valeur "1" pour la directive + CacheDirLength + est recommandée.

+

Le paramétrage de la directive + CacheDirLevels + dépend du nombre de fichiers que vous pensez stocker dans le cache. + Avec une valeur de "2" comme dans l'exemple donné plus haut, + 4096 sous-répertoires peuvent être créés au total. Avec 1 million de + fichiers dans le cache, cela équivaut à environ 245 URLs mises en cache + dans chaque répertoire.

+ +

Chaque URL nécessite au moins deux fichiers dans le cache. Ce sont en + général un fichier ".header", qui contient des meta-informations à propos + de l'URL, comme la date de son arrivée à expiration, + et un fichier ".data" qui est la copie exacte du contenu à servir.

+ +

Dans le cas d'un contenu négocié via l'en-tête "Vary", un répertoire + ".vary" sera créé pour l'URL en question. Ce répertoire contiendra de + multiples fichiers ".data" correspondant aux différents contenus + négociés.

-

Empoisonnement du cache (Cache Poisoning)

+

Maintenance du cache sur disque

-

Si vous utilisez httpd comme serveur mandataire avec mise en cache, - vous vous exposez aussi à un éventuel "Empoisonnement du - cache" (Cache poisoning). L'empoisonnement du cache est un terme général - pour désigner les attaques au cours desquelles l'attaquant fait en sorte - que le serveur mandataire renvoie à un contenu incorrect (et souvent - indésirable) suite à en provenance du serveur d'arrière-plan. -

+

Le module mod_cache_disk n'effectue aucune + régulation de l'espace disque utilisé par le cache, mais s'il + s'arrête en douceur en cas d'erreur disque et se comporte alors + comme si le cache n'avait jamais existé.

-

Par exemple, si les serveur DNS qu'utilise votre système où tourne - httpd sont vulnérables à l'empoisonnement du cache des DNS, un attaquant - pourra contrôler vers où httpd se connecte lorsqu'il demande un contenu - depuis le serveur d'origine. - Un autre exemple est constitué par les attaques ainsi nommées - "Dissimulation de requêtes HTTP" (HTTP request-smuggling).

+

Par contre l'utilitaire + htcacheclean fourni avec + httpd + vous permet de nettoyer le cache périodiquement. + Déterminer la fréquence à laquelle lancer htcacheclean et la taille souhaitée + pour le cache est une tâche relativement complexe et il vous faudra de + nombreux essais et erreurs pour arriver à sélectionner des valeurs + optimales.

-

Ce document n'est pas le bon endroit pour une discussion approfondie - à propos de la Dissimulation de requêtes HTTP (utilisez plutôt votre - moteur de recherche favori); il est cependant important de savoir qu'il - est possible d'élaborer une série de requêtes, et d'exploiter une - vulnérabilité d'un serveur web d'origine de telle façon que l'attaquant - puisse contrôler entièrement le contenu renvoyé par le mandataire.

+

htcacheclean opère selon deux + modes. Il peut s'exécuter comme démon résident, ou être lancé + périodiquement par cron. htcacheclean peut mettre une heure + ou plus pour traiter de très grands caches (plusieurs dizaines de + Gigaoctets) et si vous l'exécutez à partir de cron, il vous est + conseillé de déterminer la durée typique d'un traitement, afin d'éviter + d'exécuter plusieurs instances à la fois.

+ +

Il est aussi conseillé d'attribuer un niveau de priorité "nice" + approprié à htcacheclean de façon à ce qu'il n'effectue pas trop + d'accès disque pendant le fonctionnement du serveur.

+ +

+
+ Figure 1: Croissance + typique du cache / séquence de nettoyage.

+ +

Comme mod_cache_disk ne tient pas compte de l'espace + utilisé dans le cache, vous devez vous assurer que + htcacheclean est configuré de + façon à laisser suffisamment d'"espace de croissance" + à la suite d'un nettoyage.

+
top
-

Mise en cache de la gestion de fichier

+

Mise en cache d'objets partagés à deux états de forme + clé/valeur

+ -
Modules ApparentésDirectives Apparentées
+
Modules ApparentésDirectives Apparentées
+ +

Le serveur HTTP Apache fournit un cache d'objets partagés de bas + niveau pour la mise en cache d'informations comme les sessions SSL + ou les données d'authentification dans l'interface socache.

+ +

Pour chaque implémentation un module supplémentaire est fourni + qui offre les services d'arrière-plan suivants :

+ +
+
mod_socache_dbm
+
Cache d'objets partagés basé sur DBM.
+
mod_socache_dc
+
Cache d'objets partagés basé sur Distcache.
+
mod_socache_memcache
+
Cache d'objets partagés basé sur Memcache.
+
mod_socache_shmcb
+
Cache d'objets partagés basé sur la mémoire partagée.
+
+ +

Mise en cache des données d'authentification

+ -

Le fait d'ouvrir un fichier peut en lui-même introduire un délai, - en particulier dans les systèmes de fichiers répartis - sur le réseau. httpd - peut s'affranchir de ce délai en maintenant - un cache des descripteurs de fichiers - ouverts pour ce qui concerne les fichiers souvent - accédés. httpd propose - actuellement une implémentation de mise en cache de la - gestion de fichier.

+
Modules ApparentésDirectives Apparentées
-

Directive CacheFile

- +

Le module mod_authn_socache permet la mise en + cache des données issues d'une authentification, diminuant ainsi + la charge des serveurs d'authentification en arrière-plan.

-

La forme la plus élémentaire de mise en cache que - propose httpd est - fournie par le module mod_file_cache. - Plutôt que de mettre en cache le contenu des fichiers, ce cache maintient - une table des descripteurs de fichiers ouverts. Les fichiers à mettre en - cache de cette manière sont spécifiés dans le fichier de configuration - en utilisant la directive - CacheFile.

+ -

La directive - CacheFile demande - à httpd - d'ouvrir le fichier lors de son démarrage et de réutiliser le descripteur - de fichier élaboré à cette occasion pour tous les - accès ultérieurs à ce fichier.

+

Mise en cache des sessions SSL

+ -

- CacheFile /usr/local/apache2/htdocs/index.html -

+
Modules ApparentésDirectives Apparentées
-

Si vous avez l'intention de mettre en cache un grand nombre de - fichiers de cette manière, vous devez vous assurer que le nombre maximum - de fichiers ouverts par votre système d'exploitation est correctement - défini.

- -

Bien que l'utilisation de la directive - CacheFile - n'entraîne pas la mise en cache du contenu du fichier, cela ne signifie - pas qu'en cas de modification du fichier pendant - l'exécution de httpd, - ces changements seront pris en compte. Le fichier sera toujours servi - dans l'état où il était quand httpd a démarré.

- -

Si le fichier est supprimé pendant l'exécution de - httpd, ce dernier - continuera à maintenir un descripteur de fichier ouvert et à servir le - fichier dans l'état où il était quand httpd a démarré. Cela signifie - aussi habituellement que malgré le fait que le fichier ait été supprimé, - et ne soit - plus accessible par le système de fichiers, l'espace libéré ne sera - restitué qu'à l'arrêt de httpd quand le - descripteur de fichier sera fermé.

- +

Le module mod_ssl utilise l'interface + socache pour fournir un cache de session et un cache + de base.

+
top
-

Mise en cache en mémoire

+

Mise en cache à base de fichiers spécialisés

+ + + +
Modules ApparentésDirectives Apparentées
+ +

Sur les plateformes où le système de fichiers peut être lent, ou + lorsque les descripteurs de fichiers sont gourmands en ressources, + il est possible de précharger des fichiers en mémoire au démarrage + du serveur.

+ +

Sur les systèmes où l'ouverture des fichiers est lente, il est + possible d'ouvrir le fichier au démarrage du serveur et de mettre en + cache le descripteur de fichier. Ces options peuvent vous aider sur + les systèmes où l'accès aux fichiers statiques est lent.

+ +

Mise en cache des descripteurs de fichier

+ + +

Le processus d'ouverture d'un fichier peut être en soi une + source de ralentissement, en particulier sur les systèmes de + fichiers sur le réseau. httpd permet d'éviter ce ralentissement en + maintenant un cache des descripteurs de fichiers ouverts pour les + fichiers souvent servis. Actuellement, httpd fournit une seule + implémentation de mise en cache des descripteurs de fichiers.

+ +

CacheFile

+ + +

La forme la plus basique de mise en cache que propose httpd + est la mise en cache des descripteurs de fichiers fournie par le + module mod_file_cache. Plutôt que de mettre en + cache le contenu des fichiers, ce cache maintient une table des + descripteurs de fichiers ouverts. Les fichiers devant faire + l'objet d'une mise en cache de ce type sont spécifiés dans le + fichier de configuration via la directive CacheFile.

+ +

La directive CacheFile informe httpd + qu'il doit ouvrir le fichier lors de son démarrage et qu'il doit + réutiliser le descripteur de fichier mis en cache pour tous les + accès futurs à ce fichier.

+ +

+ CacheFile /usr/local/apache2/htdocs/index.html +

+ +

Si vous désirez mettre en cache un grand nombre de fichiers + de cette manière, vous devez vous assurer que le nombre maximal + de fichiers ouverts pour votre système d'exploitation est défini + à une valeur suffisante.

+ +

Bien que l'utilisation de la directive CacheFile n'entraîne pas de + mise en cache du contenu du fichier proprement dit, elle + implique que si le fichier est modifié pendant l'exécution du + serveur, ces modifications ne seront pas prises en compte. Le + fichier sera toujours servi dans l'état où il se trouvait au + moment du démarrage du serveur.

+ +

Si le fichier est supprimé pendant l'exécution du serveur, ce + dernier conservera le descripteur de fichier ouvert associé et + servira le fichier dans l'état où il se trouvait au + moment du démarrage du serveur. Cela signifie aussi que même si + le fichier a été supprimé, et n'apparaît donc plus dans le + système de fichiers, l'espace disque libéré ne sera disponible + qu'une fois le serveur httpd arrêté et donc le descripteur de + fichier fermé.

+ + -
Modules ApparentésDirectives Apparentées
+

In-Memory Caching

+

Servir un contenu directement depuis la mémoire système est universellement reconnu comme la méthode la plus rapide. Lire des fichiers @@ -516,7 +715,7 @@ Vary: negotiate,accept-language,accept-charset Sinon le système sera contraint d'utiliser le swap, ce qui dégradera sensiblement les performances.

-

Mise en cache par l'intermédiaire du système d'exploitation

+

Mise en cache par l'intermédiaire du système d'exploitation

Dans la plupart des systèmes d'exploitation modernes, c'est le noyau @@ -527,7 +726,7 @@ Vary: negotiate,accept-language,accept-charset temps nécessaire à la première lecture d'un fichier et le temps nécessaire à sa deuxième lecture;

- 
+        
 colm@coroebus:~$ time cat testfile > /dev/null
 real    0m0.065s
 user    0m0.000s
@@ -554,14 +753,14 @@ sys     0m0.000s

       avantage par rapport à la mise en cache en mémoire
       de httpd qui n'a
       aucune possibilité de savoir si un fichier a été modifié.

-    
+      
 
     
En dépit des performances et des avantages de la mise en cache
     automatique par le système d'exploitation, la mise en cache en mémoire
     peut être effectuée plus efficacement par httpd dans certaines
     circonstances.

 
-    
Mise en cache à l'aide de la directive MMapFile

+    
Mise en cache à l'aide de la directive MMapFile

       
 
       
La directive MMapFile
@@ -572,9 +771,9 @@ sys     0m0.000s
utilisera le contenu chargé en mémoire pour satisfaire ultérieurement toutes les demandes d'accès à ce fichier.

-

- MMapFile /usr/local/apache2/htdocs/index.html -

+

+ MMapFile /usr/local/apache2/htdocs/index.html +

Comme dans le cas de la directive CacheFile, toute @@ -588,139 +787,141 @@ sys 0m0.000s

sa propre réplique de la mémoire allouée, il est donc d'une importance critique de s'assurer que les fichiers chargés ne sont pas d'une taille trop importante afin d'épargner au système l'utilisation du swap.

+ -
top
-

Mise en cache sur disque

+

Considérations sur la sécurité

-
Modules ApparentésDirectives Apparentées
- -

Le module mod_cache_disk fournit un mécanisme de mise - en cache sur disque au module mod_cache. Cette mise en cache est - intelligente et le contenu ne sera servi qu'à partir du cache tant qu'il - sera considéré comme valide.

- -

Typiquement, le module sera configuré comme suit :

+

Autorisation et contrôle d'accès

+ -

-CacheRoot /var/cache/apache/
-CacheEnable disk /
-CacheDirLevels 2
-CacheDirLength 1 -

+

Utiliser mod_cache revient sensiblement à la même + chose qu'avoir un mandataire inverse intégré (reverse-proxy). Les requêtes + seront servies par le module de mise en cache sauf si ce dernier + détermine qu'un processus d'arrière-plan doit être appelé. La mise en + cache de ressources locales modifie considérablement le modèle de + sécurité de httpd.

-

Il est important de savoir que, les fichiers mis en cache étant stockés - localement, la mise en cache par l'intermédiaire du système d'exploitation - sera en général aussi appliquée à leurs accès. Si bien que même si les - fichiers sont stockés sur disque, s'il font l'objet d'accès fréquents, - il est probable que le système d'exploitation s'appliquera à ce qu'ils - soient servis à partir de la mémoire.

+

Comme le parcours de la hiérarchie d'un système de fichiers pour + examiner le contenu d'éventuels fichiers + .htaccess serait une opération très coûteuse en ressources, + annulant partiellement de ce fait l'intérêt de la mise en cache + (accélérer le traitement des requêtes), + mod_cache ne se préoccupe pas de savoir s'il a + l'autorisation de servir une entité mise en cache. En d'autres termes, + si mod_cache a mis en cache un certain contenu, ce + dernier sera servi à partir du cache tant qu'il ne sera pas arrivé à + expiration.

-

Comprendre le stockage dans le cache

- +

Si par exemple, votre configuration autorise l'accès à une ressource + en fonction de l'adresse IP, vous devez vous assurer que ce contenu n'est + pas mis en cache. Ceci est possible en utilisant la directive + CacheDisable, ou le module + mod_expires. Livré à lui-même, + mod_cache - pratiquement comme un mandataire inverse - + mettrait en cache le contenu lors de son service, et le servirait ensuite + à tout client, vers n'importe quelle adresse IP.

-

Pour stocker des entités dans le cache, - le module mod_cache_disk crée une empreinte (hash) de 22 - caractères de l'URL qui a fait l'objet d'une requête. Cette empreinte - comprend le nom d'hôte, le protocole, le port, le chemin et tout argument - de type CGI associé à l'URL, afin d'être sur que plusieurs URLs - n'interfèrent pas entre elles.

+

Lorsque la directive CacheQuickHandler est définie à + Off, toutes les phases du traitement de la requête + sont exécutées et le modèle de sécurité reste le même.

-

Chaque position de l'empreinte peut contenir un caractère - choisi parmi 64 caractères différents, il y a donc - 64^22 possibilités pour une empreinte. Par exemple, une URL peut posséder - l'empreinte xyTGxSMO2b68mBCykqkp1w. Cette empreinte est - utilisée pour préfixer les noms de fichiers spécifiques à cette URL à - l'intérieur du cache; cependant, elle est tout d'abord placée dans les - répertoires du cache selon les directives - CacheDirLevels et - CacheDirLength.

+ -

La directive - CacheDirLevels - définit le nombre de niveaux de sous-répertoires, et - CacheDirLength - le nombre de caractères composant le nom des sous-répertoires. Dans - l'exemple donné plus haut, l'empreinte se trouvera à : - /var/cache/apache/x/y/TGxSMO2b68mBCykqkp1w.

+

Piratages locaux

+ -

Cette technique a pour but principal de réduire le nombre de - sous-répertoires ou de fichiers contenus dans un répertoire particulier, - car le fonctionnement de la plupart des systèmes de fichiers est ralenti - quand ce nombre augmente. Avec la valeur "1" pour la directive - CacheDirLength, - il peut y avoir au plus 64 sous-répertoires à un niveau quelconque. - Avec la valeur "2", il peut y en avoir 64 * 64, etc... - A moins d'avoir une bonne raison pour ne pas le faire, l'utilisation de - la valeur "1" pour la directive - CacheDirLength - est recommandée.

+

Etant donné que les requêtes des utilisateurs finaux peuvent être + servies depuis le cache, ce dernier est une cible potentielle pour ceux + qui veulent défigurer un contenu ou interférer avec lui. Il est important + de garder à l'esprit que l'utilisateur sous lequel tourne + httpd doit + toujours avoir l'accès en écriture dans le cache. Ceci est en contraste + total avec la recommandation usuelle d'interdire à l'utilisateur sous + lequel tourne Apache + l'accès en écriture à tout contenu.

-

Le paramétrage de la directive - CacheDirLevels - dépend du nombre de fichiers que vous pensez stocker dans le cache. - Avec une valeur de "2" comme dans l'exemple donné plus haut, - 4096 sous-répertoires peuvent être créés au total. Avec 1 million de - fichiers dans le cache, cela équivaut à environ 245 URLs mises en cache - dans chaque répertoire.

+

Si l'utilisateur sous lequel tourne Apache est compromis, + par exemple à cause d'une + faille de sécurité dans un processus CGI, il est possible que le cache + fasse l'objet d'une attaque. Il est relativement aisé d'insérer ou de + modifier une entité dans le cache en utilisant le module + mod_cache_disk.

-

Chaque URL nécessite au moins deux fichiers dans le cache. Ce sont en - général un fichier ".header", qui contient des meta-informations à propos - de l'URL, comme la date de son arrivée à expiration, - et un fichier ".data" qui est la copie exacte du contenu à servir.

+

Cela représente un risque relativement élévé par rapport aux autres + types d'attaques qu'il est possible de mener sous l'utilisateur apache. + Si vous utilisez mod_cache_disk, vous devez garder ceci + à l'esprit : effectuez toujours les mises à jour de + httpdquand des + correctifs de sécurité sont annoncés et exécutez les processus CGI sous + un utilisateur autre qu'apache en utilisant + suEXEC dans la mesure du possible.

-

Dans le cas d'un contenu négocié via l'en-tête "Vary", un répertoire - ".vary" sera créé pour l'URL en question. Ce répertoire contiendra de - multiples fichiers ".data" correspondant aux différents contenus - négociés.

-

Maintenance du cache sur disque

+

Empoisonnement du cache (Cache Poisoning)

-

Bien que le module mod_cache_disk supprime un contenu - du cache lorsqu'il est arrivé à expiration, il ne maintient aucune - information à propos de la taille totale du cache ou de l'espace restant - disponible.

+

Si vous utilisez httpd comme serveur mandataire avec mise en cache, + vous vous exposez aussi à un éventuel "Empoisonnement du + cache" (Cache poisoning). L'empoisonnement du cache est un terme général + pour désigner les attaques au cours desquelles l'attaquant fait en sorte + que le serveur mandataire renvoie à un contenu incorrect (et souvent + indésirable) suite à en provenance du serveur d'arrière-plan. +

-

Par contre l'utilitaire - htcacheclean fourni avec - httpd - vous permet, comme son nom l'indique, de nettoyer le cache périodiquement. - Déterminer la fréquence à laquelle lancer htcacheclean et la taille souhaitée - pour le cache est une tâche relativement complexe et il vous faudra de - nombreux essais et erreurs pour arriver à sélectionner des valeurs - optimales.

+

Par exemple, si les serveur DNS qu'utilise votre système où tourne + httpd sont vulnérables à l'empoisonnement du cache des DNS, un attaquant + pourra contrôler vers où httpd se connecte lorsqu'il demande un contenu + depuis le serveur d'origine. + Un autre exemple est constitué par les attaques ainsi nommées + "Dissimulation de requêtes HTTP" (HTTP request-smuggling).

-

htcacheclean opère selon deux - modes. Il peut s'exécuter comme démon résident, ou être lancé - périodiquement par cron. htcacheclean peut mettre une heure - ou plus pour traiter de très grands caches (plusieurs dizaines de - Gigaoctets) et si vous l'exécutez à partir de cron, il vous est - conseillé de déterminer la durée typique d'un traitement, afin d'éviter - d'exécuter plusieurs instances à la fois.

+

Ce document n'est pas le bon endroit pour une discussion approfondie + à propos de la Dissimulation de requêtes HTTP (utilisez plutôt votre + moteur de recherche favori); il est cependant important de savoir qu'il + est possible d'élaborer une série de requêtes, et d'exploiter une + vulnérabilité d'un serveur web d'origine de telle façon que l'attaquant + puisse contrôler entièrement le contenu renvoyé par le mandataire.

+ -

-
- Figure 1: Croissance - typique du cache / séquence de nettoyage.

+

Déni de Service / Cachebusting

+ -

Comme mod_cache_disk ne tient pas compte de l'espace - utilisé dans le cache, vous devez vous assurer que - htcacheclean est configuré de - façon à laisser suffisamment d'"espace de croissance" - à la suite d'un nettoyage.

+

Le mécanisme utilisé via l'en-tête Vary permet de mettre en + cache simultanément plusieurs variantes d'une ressource avec la + même URL. Le cache sélectionne la variante correcte à envoyer au + client en fonction des valeurs d'en-tête fournies par ce dernier. + Ce mécanisme peut devenir un problème lorsqu'on tente d'appliquer + le mécanisme des variantes à un en-tête connu pour pouvoir + posséder un grand nombre de valeurs + possibles en utilisation normal, comme par exemple l'en-tête + User-Agent. En fonction de la popularité du site web, + des milliers ou même des millions d'entrées de cache dupliquées + peuvent être créées pour la même URL, submergeant les autres + entrées du cache.

+ +

Dans d'autres cas, il peut être nécessaire de modifier l'URL + d'une ressource particulière à chaque requête, en général en lui + ajoutant une chaîne "cachebuster". Si ce contenu est déclaré comme + pouvant être mis en cache par un serveur avec une durée de + fraîcheur significative, ces entrées peuvent submerger les entrées + légitimes du cache. Alors que mod_cache fournit + une directive CacheIgnoreURLSessionIdentifiers, + cette dernière doit être utilisée avec prudence pour s'assurer que + les caches du navigateur ou du mandataire le plus proche + (downstream proxy) ne sont pas victimes du même problème de Déni de + service.

-

Langues Disponibles:  en  |  fr  |  tr 

\ No newline at end of file diff --git a/docs/manual/caching.html.tr.utf8 b/docs/manual/caching.html.tr.utf8 index ef796c04225..0c829ad5985 100644 --- a/docs/manual/caching.html.tr.utf8 +++ b/docs/manual/caching.html.tr.utf8 @@ -632,6 +632,6 @@  fr  |  tr 

\ No newline at end of file diff --git a/docs/manual/compliance.html.en b/docs/manual/compliance.html.en index 212c869c2f0..90f809cde88 100644 --- a/docs/manual/compliance.html.en +++ b/docs/manual/compliance.html.en @@ -461,6 +461,6 @@

Available Languages:  en 

\ No newline at end of file diff --git a/docs/manual/configuring.html.de b/docs/manual/configuring.html.de index 9aaa80bde02..be01afd15bc 100644 --- a/docs/manual/configuring.html.de +++ b/docs/manual/configuring.html.de @@ -185,6 +185,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/configuring.html.en b/docs/manual/configuring.html.en index f647d2ab604..a4828c143c6 100644 --- a/docs/manual/configuring.html.en +++ b/docs/manual/configuring.html.en @@ -200,6 +200,6 @@ Server.

 ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/configuring.html.fr b/docs/manual/configuring.html.fr index c9bb1dcbaa3..03352ebc4f4 100644 --- a/docs/manual/configuring.html.fr +++ b/docs/manual/configuring.html.fr @@ -209,6 +209,6 @@ le Serveur HTTP Apache.

 ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/configuring.html.ja.utf8 b/docs/manual/configuring.html.ja.utf8 index 3d74d568795..0b19bbb9787 100644 --- a/docs/manual/configuring.html.ja.utf8 +++ b/docs/manual/configuring.html.ja.utf8 @@ -173,6 +173,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/configuring.html.ko.euc-kr b/docs/manual/configuring.html.ko.euc-kr index 20be410e80b..01f650b4bc4 100644 --- a/docs/manual/configuring.html.ko.euc-kr +++ b/docs/manual/configuring.html.ko.euc-kr @@ -151,6 +151,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/configuring.html.tr.utf8 b/docs/manual/configuring.html.tr.utf8 index dfdd0956a35..8428985df9e 100644 --- a/docs/manual/configuring.html.tr.utf8 +++ b/docs/manual/configuring.html.tr.utf8 @@ -197,6 +197,6 @@ açıklanmıştır.

 ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/content-negotiation.html.en b/docs/manual/content-negotiation.html.en index 1b346f69207..fd0210ae30b 100644 --- a/docs/manual/content-negotiation.html.en +++ b/docs/manual/content-negotiation.html.en @@ -679,6 +679,6 @@ factors to 5 decimal places before choosing the best variant.

 ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/content-negotiation.html.fr b/docs/manual/content-negotiation.html.fr index 4a66bf305b4..607f1a103a8 100644 --- a/docs/manual/content-negotiation.html.fr +++ b/docs/manual/content-negotiation.html.fr @@ -710,6 +710,6 @@ conventions de nommage  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/content-negotiation.html.ja.utf8 b/docs/manual/content-negotiation.html.ja.utf8 index 00f943e7635..88dc9adc6fb 100644 --- a/docs/manual/content-negotiation.html.ja.utf8 +++ b/docs/manual/content-negotiation.html.ja.utf8 @@ -720,6 +720,6 @@ RVSA/1.0 の実装では、最適な variant が見つかるまで、  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/content-negotiation.html.ko.euc-kr b/docs/manual/content-negotiation.html.ko.euc-kr index c5bbb8852fb..e1634f95da7 100644 --- a/docs/manual/content-negotiation.html.ko.euc-kr +++ b/docs/manual/content-negotiation.html.ko.euc-kr @@ -601,6 +601,6 @@ content-encoding  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/content-negotiation.html.tr.utf8 b/docs/manual/content-negotiation.html.tr.utf8 index 9eed4ca26d7..22d308c40de 100644 --- a/docs/manual/content-negotiation.html.tr.utf8 +++ b/docs/manual/content-negotiation.html.tr.utf8 @@ -648,6 +648,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/custom-error.html.en b/docs/manual/custom-error.html.en index 2dc43d69154..f6ace8b257d 100644 --- a/docs/manual/custom-error.html.en +++ b/docs/manual/custom-error.html.en @@ -210,6 +210,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/custom-error.html.es b/docs/manual/custom-error.html.es index 37283279157..f777c934697 100644 --- a/docs/manual/custom-error.html.es +++ b/docs/manual/custom-error.html.es @@ -222,6 +222,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/custom-error.html.fr b/docs/manual/custom-error.html.fr index 0c1e1d8a672..4c4517936c7 100644 --- a/docs/manual/custom-error.html.fr +++ b/docs/manual/custom-error.html.fr @@ -223,6 +223,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/custom-error.html.ja.utf8 b/docs/manual/custom-error.html.ja.utf8 index 16326cc6b53..44efc31df47 100644 --- a/docs/manual/custom-error.html.ja.utf8 +++ b/docs/manual/custom-error.html.ja.utf8 @@ -197,6 +197,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/custom-error.html.ko.euc-kr b/docs/manual/custom-error.html.ko.euc-kr index b9acf2eaf28..62575002bc9 100644 --- a/docs/manual/custom-error.html.ko.euc-kr +++ b/docs/manual/custom-error.html.ko.euc-kr @@ -199,6 +199,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/custom-error.html.tr.utf8 b/docs/manual/custom-error.html.tr.utf8 index 2800522c81b..d56c6bf3364 100644 --- a/docs/manual/custom-error.html.tr.utf8 +++ b/docs/manual/custom-error.html.tr.utf8 @@ -201,6 +201,6 @@  ko  |  tr 

\ No newline at end of file diff --git a/docs/manual/developer/API.html.en b/docs/manual/developer/API.html.en index 9c3b9561c2a..f5f506b6f24 100644 --- a/docs/manual/developer/API.html.en +++ b/docs/manual/developer/API.html.en @@ -1217,6 +1217,6 @@ void *request_config; /* Notes on *this* request */

Available Languages:  en 

\ No newline at end of file diff --git a/docs/manual/developer/debugging.html.en b/docs/manual/developer/debugging.html.en index 5e0c848ee3f..e2cc8d1d205 100644 --- a/docs/manual/developer/debugging.html.en +++ b/docs/manual/developer/debugging.html.en @@ -29,6 +29,6 @@

Available Languages:  en 

\ No newline at end of file diff --git a/docs/manual/developer/documenting.html.en b/docs/manual/developer/documenting.html.en index 0b034a2406d..c7045697c07 100644 --- a/docs/manual/developer/documenting.html.en +++ b/docs/manual/developer/documenting.html.en @@ -81,6 +81,6 @@

Available Languages:  en  |  zh-cn 

\ No newline at end of file diff --git a/docs/manual/developer/documenting.html.zh-cn b/docs/manual/developer/documenting.html.zh-cn index 81664896e75..e2b4c3a9263 100644 --- a/docs/manual/developer/documenting.html.zh-cn +++ b/docs/manual/developer/documenting.html.zh-cn @@ -77,6 +77,6 @@

可用语言:  en  |  zh-cn 

\ No newline at end of file diff --git a/docs/manual/developer/filters.html.en b/docs/manual/developer/filters.html.en index 51af86d3706..445d8803244 100644 --- a/docs/manual/developer/filters.html.en +++ b/docs/manual/developer/filters.html.en @@ -205,6 +205,6 @@ Default_handler --> sub_request_core

Available Languages:  en 

\ No newline at end of file diff --git a/docs/manual/developer/hooks.html.en b/docs/manual/developer/hooks.html.en index cc6ad860901..5b586089b56 100644 --- a/docs/manual/developer/hooks.html.en +++ b/docs/manual/developer/hooks.html.en @@ -234,6 +234,6 @@

Available Languages:  en 

\ No newline at end of file diff --git a/docs/manual/developer/index.html.en b/docs/manual/developer/index.html.en index 5be74342061..4683b8f62b7 100644 --- a/docs/manual/developer/index.html.en +++ b/docs/manual/developer/index.html.en @@ -66,6 +66,6 @@

Available Languages:  en  |  zh-cn 

\ No newline at end of file diff --git a/docs/manual/developer/index.html.zh-cn b/docs/manual/developer/index.html.zh-cn index ea67e9ce1e6..897d0291891 100644 --- a/docs/manual/developer/index.html.zh-cn +++ b/docs/manual/developer/index.html.zh-cn @@ -73,6 +73,6 @@

可用语言:  en  |  zh-cn 

\ No newline at end of file diff --git a/docs/manual/developer/modules.html.en b/docs/manual/developer/modules.html.en index f7ecb80eecd..8d75aed2baf 100644 --- a/docs/manual/developer/modules.html.en +++ b/docs/manual/developer/modules.html.en @@ -278,6 +278,6 @@ module MODULE_VAR_EXPORT module_name_module =

Available Languages:  en  |  ja 

\ No newline at end of file diff --git a/docs/manual/developer/modules.html.ja.utf8 b/docs/manual/developer/modules.html.ja.utf8 index 6a81083188a..e1cb1f2849d 100644 --- a/docs/manual/developer/modules.html.ja.utf8 +++ b/docs/manual/developer/modules.html.ja.utf8 @@ -272,6 +272,6 @@ module MODULE_VAR_EXPORT module_name_module =

言語:  en  |  ja 

\ No newline at end of file diff --git a/docs/manual/developer/new_api_2_4.html.en b/docs/manual/developer/new_api_2_4.html.en index 6a4c68cd320..93d33f97ec2 100644 --- a/docs/manual/developer/new_api_2_4.html.en +++ b/docs/manual/developer/new_api_2_4.html.en @@ -164,8 +164,9 @@