Serveur Apache HTTP Version 2.3
+
Module Apache mod_cache
+ +| Description: | Mise en cache de contenu référencé par un +URI. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | cache_module |
| Fichier Source: | mod_cache.c |
Sommaire
+ +CacheQuickHandler est définie à sa
+ valeur par défaut on, les directives Allow and Deny sont court-circuitées. Vous
+ ne devez donc pas activer la gestion rapide de la mise en cache pour
+ un contenu auquel vous souhaitez limiter l'accès en fonction du nom
+ d'hôte du client, de l'adresse IP ou d'une variable
+ d'environnement.mod_cache implémente une mise en cache de
+ contenu HTTP compatible RFC 2616 qui peut
+ être utilisée pour mettre en cache des contenus locaux ou mandatés.
+ mod_cache requiert les services d'un ou plusieurs
+ modules de gestion de stockage. La distribution Apache de base
+ inclut un module de gestion de stockage :
-
+
mod_disk_cache
+ - implémente un gestionnaire de stockage sur disque. +
Les contenus sont stockés dans le cache et extraits de ce dernier + en utilisant une clé à base d'URI. Un contenu dont l'accès est + protégé ne sera pas mis en cache.
+Pour de plus amples détails, une description, et des exemples, + reportez-vous au Guide de la mise en + cache.
+Directives
+-
+
CacheDefaultExpire
+- CacheDisable
+
- CacheEnable
+
- CacheIgnoreCacheControl
+
- CacheIgnoreHeaders
+
- CacheIgnoreNoLastMod
+
- CacheIgnoreQueryString
+
- CacheIgnoreURLSessionIdentifiers
+
- CacheLastModifiedFactor
+
- CacheLock
+
- CacheLockMaxAge
+
- CacheLockPath
+
- CacheMaxExpire
+
- CacheMinExpire
+
- CacheQuickHandler
+
- CacheStoreNoStore
+
- CacheStorePrivate
+
Sujets
+-
+
- Modules apparentés et directives
+
- Exemple de configuration
+
- Eviter une tempête de requête
+
- Contrôle fin via le filtre CACHE
+
Voir aussi
+
Modules apparentés et directives
+| Modules Apparentés | Directives Apparentées |
|---|---|
Exemple de configuration
+Extrait de httpd.conf
+ #
+ # Exemple de configuration du cache
+ #
+ LoadModule cache_module modules/mod_cache.so
+
+ <IfModule mod_cache.c>
+
+ LoadModule disk_cache_module modules/mod_disk_cache.so
+ <IfModule mod_disk_cache.c>
+
+ CacheRoot c:/cacheroot
+ CacheEnable disk /
+ CacheDirLevels 5
+ CacheDirLength 3
+
+ </IfModule>
+
+ # Lorsqu'on sert de mandataire, on ne met pas en cache la liste
+ # des mises à jour de sécurité
+ CacheDisable http://security.update.server/update-list/
+
+ </IfModule>
+
Eviter une tempête de requête
+Lorsqu'une entrée du cache est périmée, mod_cache
+ soumet une requête conditionnelle au processus d'arrière-plan, qui est
+ censé confirmer la validité de l'entrée du cache, ou dans la négative
+ envoyer une entrée mise à jour.
Un court mais non négligeable laps de temps existe entre le moment + où l'entrée du cache est périmée, et le moment où elle est mise à + jour. Sur un serveur fortement chargé, un certain nombre de requêtes + peut arriver pendant ce laps de temps, et provoquer une + tempête de requêtes susceptibles de saturer le + processus d'arrière-plan de manière soudaine et imprédictible.
+Pour contenir cette tempête, on peut utiliser la directive
+ CacheLock afin de définir un répertoire où
+ seront créés à la volée des verrous pour les URLs.
+ Ces verrous sont utilisés comme autant d'indications
+ par les autres requêtes, soit pour empêcher une tentative de mise en
+ cache (un autre processus est en train de récupérer l'entité), soit
+ pour indiquer qu'une entrée périmée est en cours de mise à jour
+ (pendant ce temps, c'est le contenu périmé qui sera renvoyé).
+
Mise en cache initiale d'une entrée
+ +Lorsqu'une entité est mise en cache pour la première fois, un + verrou est créé pour cette entité jusqu'à ce que la réponse ait été + entièrement mise en cache. Pendant la durée de vie du verrou, le + cache va empêcher une seconde tentative de mise en cache de la même + entité. Bien que cela ne suffise pas à contenir la tempête de + requêtes, toute tentative de mettre en cache la même entité + plusieurs fois simultanément est stoppée. +
+ +Mise à jour d'une entrée périmée
+ +Lorsqu'une entrée atteint la limite de sa durée de vie, et + devient par conséquent périmée, un verrou est créé pour cette entité + jusqu'à ce que la réponse ait été soit confirmée comme encore + valide, soit remplacée par le processus d'arrière-plan. Pendant la + durée de vie du verrou, une seconde requête entrante va provoquer le + renvoi de la donnée périmée, et la tempête de requêtes sera + contenue.
+ +Verrous et en-tête Cache-Control: no-cache
+ +Les verrous ne sont utilisés qu'à titre + indicatif pour enjoindre le cache à être plus coopératif + avec les serveurs d'arrière-plan, et il est possible de passer outre + si nécessaire. Si le client envoie une requête contenant un en-tête + Cache-Control imposant un nouveau téléchargement de l'entité, tout + verrou éventuel sera ignoré, la requête du client sera honorée + immédiatement, et l'entrée du cache mise à jour.
+ +Comme mécanisme de sécurité supplémentaire, la durée de vie
+ maximale des verrous est configurable. Lorsque cette limite est
+ atteinte, le verrou est supprimé et une autre requête peut alors en
+ créer un nouveau. Cette durée de vie peut être définie via la
+ directive CacheLockMaxAge, et sa valeur par
+ défaut est de 5 secondes.
+
Exemple de configuration
+ +Activation du verrouillage du cache
+ #
+ # Active le verrouillage du cache
+ #
+ <IfModule mod_cache.c>
+
+ CacheLock on
+ CacheLockPath /tmp/mod_cache-lock
+ CacheLockMaxAge 5
+
+ </IfModule>
+
Contrôle fin via le filtre CACHE
+Dans son mode de fonctionnement par défaut, le cache s'exécute sous + la forme d'un gestionnaire rapide, court-circuitant la majorité des + traitements du serveur et fournissant ainsi une mise en cache + possédant les plus hautes performances disponibles.
+ +Dans ce mode, le cache s'incruste devant le + serveur, comme si un mandataire de mise en cache indépendant RFC2616 + était placé devant ce dernier.
+ +Bien que que ce mode offre les meilleures performances, les + administrateurs peuvent souhaiter, dans certaines circonstances, + effectuer des traitements sur la requête après que cette dernière ait + été mise en cache, comme ajouter du contenu personnalisé à la page + mise en cache, ou appliquer des restrictions d'autorisations au + contenu. Pour y parvenir, l'administrateur sera alors souvent forcé de + placer des serveurs mandataires inverses indépendants soit derrière, + soit devant le serveur de mise en cache.
+ +Pour résoudre ce problème, la directive CacheQuickHandler peut être définie à
+ off, afin que le serveur traite toutes les phases
+ normalement exécutées par une requête non mise en cache, y compris les
+ phases d'authentification et d'autorisation.
En outre, l'administrateur peut éventuellement spécifier le + point précis dans la chaîne de filtrage où devra + intervenir la mise en cache en ajoutant le filtre + CACHE à la chaîne de filtrage en sortie.
+ +Par exemple, pour mettre en cache le contenu avant d'appliquer une + compression à la réponse, placez le filtre CACHE + avant le filtre DEFLATE comme dans l'exemple suivant + :
+ +
+ # Mise en cache du contenu avant la compression optionnelle
+ CacheQuickHandler off
+ AddOutputFilterByType CACHE;DEFLATE text/plain
+
Une autre possibilité consiste à mettre en cache le contenu avant
+ l'ajout de contenu personnalisé via mod_include (ou
+ tout autre filtre de traitement de contenu). Dans l'exemple suivant,
+ les modèles contenant des balises comprises par
+ mod_include sont mis en cache avant d'être
+ interprétés :
+ # Mise en cache du contenu avant l'intervention de mod_include et
+ # mod_deflate
+ CacheQuickHandler off
+ AddOutputFilterByType CACHE;INCLUDES;DEFLATE text/html
+
Vous pouvez insérer le filtre CACHE en tout point
+ de la chaîne de filtrage. Dans l'exemple suivant, le contenu est mis
+ en cache après avoir été interprété par mod_include,
+ mais avant d'être traité par mod_deflate :
+ # Mise en cache du contenu entre les interventions de mod_include et
+ # mod_deflate
+ CacheQuickHandler off
+ AddOutputFilterByType INCLUDES;CACHE;DEFLATE text/html
+
Avertissement :
Si pour une raison + ou pour une autre, le point d'insertion du filtre + CACHE dans la chaîne de filtrage est modifié, vous + devez vider votre cache pour être sûr que les données + servies soient à jour. En effet,mod_cache n'est pas
+ en mesure d'effectuer cette opération à votre place.CacheDefaultExpire Directive
+| Description: | La durée par défaut de mise en cache d'un document +lorsqu'aucune date d'expiration n'a été spécifiée. |
|---|---|
| Syntaxe: | CacheDefaultExpire secondes |
| Défaut: | CacheDefaultExpire 3600 (une heure) |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheDefaultExpire permet de
+ spécifier un temps par défaut, en secondes, pendant lequel sera
+ conservé dans le cache un document qui ne possède ni date
+ d'expiration, ni date de dernière modification. La valeur de cette
+ directive est écrasée par la valeur de la directive
+ CacheMaxExpire si cette dernière est
+ utilisée.
+ CacheDefaultExpire 86400
+
CacheDisable Directive
+| Description: | Désactive la mise en cache des URLs +spécifiées |
|---|---|
| Syntaxe: | CacheDisable chaîne-url | on |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheDisable enjoint
+ mod_cache de ne pas mettre en cache l'URL
+ spécifiée par chaîne URL, ainsi que les URLs de niveaux
+ inférieurs.
Exemple
+ CacheDisable /fichiers_locaux
+
Si la directive se trouve à l'intérieur d'une section <Location>, le chemin doit être spécifié en
+ dessous de la Location, et si le mot "on" est utilisé, la mise en
+ cache sera désactivée pour l'ensemble de l'arborescence concernée
+ par la section Location.
Exemple
+ <Location /foo>
+ CacheDisable on
+ </Location>
+
Avec les versions 2.2.12 et ultérieures, on peut définir la
+ variable d'environnement no-cache pour une définition
+ plus fine des ressources à mettre en cache.
Voir aussi
+ +CacheEnable Directive
+| Description: | Active la mise en cache des URLs spécifiées en utilisant le +gestionnaire de stockage précisé |
|---|---|
| Syntaxe: | CacheEnable type de cache chaîne URL |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheEnable enjoint
+ mod_cache de mettre en cache l'URL précisée par
+ chaîne URL, ainsi que les URLs de niveaux inférieurs. Le
+ gestionnaire de stockage du cache est spécifié à l'aide de
+ l'argument type de cache. Si la directive
+ CacheEnable est située à l'intérieur d'une
+ section <Location>, le paramètre
+ url-string devient optionnel. Si type de cache
+ a pour valeur disk, mod_cache
+ utilisera le gestionnaire de stockage sur disque implémenté par
+ mod_disk_cache.
Si les différentes directives CacheEnable
+ spécifient des URLs qui se recoupent (comme dans l'exemple
+ ci-dessous), tous les gestionnaires de stockage possibles seront
+ lancés, jusqu'au premier d'entre eux qui traitera effectivement la
+ requête.
+ L'ordre dans lequel les gestionnaires de stockage sont lancés est
+ déterminé par l'ordre dans lequel apparaissent les directives
+ CacheEnable dans le fichier de
+ configuration.
En fonctionnement du type serveur mandataire direct, chaîne + URL peut aussi être utilisé pour spécifier des sites distants + et des protocoles de mandat pour lesquels la mise en cache devra + être activée.
+ +
+ # Mise en cache des URLs mandatées
+ CacheEnable disk /
+ # Mise en cache des URLs FTP mandatées
+ CacheEnable disk ftp://
+ # Mise en cache des contenus situés dans www.apache.org
+ CacheEnable disk http://www.apache.org/
+
Un nom d'hôte commençant par un caractère "*" + correspondra à tout nom d'hôte se terminant par le suffixe + considéré. Un nom d'hôte commençant par un caractère + "." correspondra à tout nom d'hôte contenant le + composant de nom de domaine qui suit ce caractère.
+ +
+ # Correspond à www.apache.org et fooapache.org
+ CacheEnable disk http://*apache.org/
+ # Correspond à www.apache.org, mais pas à fooapache.org
+ CacheEnable disk http://.apache.org/
+
Depuis la version 2.2.12, on peut définir la variable
+ d'environnement no-cache pour une définition plus fine
+ des ressources à mettre en cache.
Voir aussi
+ +CacheIgnoreCacheControl Directive
+| Description: | Ignore les en-têtes de requête enjoignant de ne pas servir +le contenu au client depuis le cache |
|---|---|
| Syntaxe: | CacheIgnoreCacheControl On|Off |
| Défaut: | CacheIgnoreCacheControl Off |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
Normalement, les requêtes contenant des en-têtes tels que
+ Cache-Control: no-cache ou Pragma: no-cache ne sont pas servies
+ depuis le cache. La directive
+ CacheIgnoreCacheControl permet de modifier ce
+ comportement. Avec CacheIgnoreCacheControl
+ On, le serveur tentera de servir la ressource depuis le
+ cache, même si la requête contient un des en-têtes cités plus haut.
+ Les ressources qui requièrent une autorisation ne seront
+ jamais mises en cache.
+ CacheIgnoreCacheControl On
+
Avertissement :
+ Cette directive permet de servir des ressources depuis le cache, + même si le client a demandé à ce qu'il n'en soit pas ainsi. Le + contenu servi est ainsi susceptible d'être périmé. +Voir aussi
+ +CacheIgnoreHeaders Directive
+| Description: | Ne pas stocker le(s) en-tête(s) spécifié(s) dans le cache. + |
|---|---|
| Syntaxe: | CacheIgnoreHeaders en-tête [en-tête] ... |
| Défaut: | CacheIgnoreHeaders None |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
En accord avec la RFC 2616, les en-têtes HTTP hop-by-hop ne sont
+ pas stockés dans le cache. Les en-têtes HTTP suivant sont des
+ en-têtes hop-by-hop, et en tant que tels, ne sont en aucun
+ cas stockés dans le cache, quelle que soit la définition de la
+ directive CacheIgnoreHeaders :
-
+
Connection
+ Keep-Alive
+ Proxy-Authenticate
+ Proxy-Authorization
+ TE
+ Trailers
+ Transfer-Encoding
+ Upgrade
+
La directive CacheIgnoreHeaders permet de
+ spécifier quels en-têtes HTTP ne doivent pas être stockés dans le
+ cache. Par exemple, il peut s'avérer pertinent dans certains cas de
+ ne pas stocker les cookies dans le cache.
La directive CacheIgnoreHeaders accepte
+ une liste d'en-têtes HTTP séparés par des espaces, qui ne doivent
+ pas être stockés dans le cache. Si les en-têtes hop-by-hop sont les
+ seuls à ne pas devoir être stockés dans le cache (le comportement
+ compatible RFC 2616), la directive
+ CacheIgnoreHeaders peut être définie à
+ None.
Exemple 1
+ CacheIgnoreHeaders Set-Cookie
+
Exemple 2
+ CacheIgnoreHeaders None
+
Avertissement :
+ Si des en-têtes nécessaires à la bonne gestion du cache, comme +Expires, ne sont pas stockés suite à la définition
+ d'une directive CacheIgnoreHeaders, le
+ comportement de mod_cache sera imprévisible.
+ CacheIgnoreNoLastMod Directive
+| Description: | Ignore le fait qu'une réponse ne possède pas d'en-tête Last +Modified. |
|---|---|
| Syntaxe: | CacheIgnoreNoLastMod On|Off |
| Défaut: | CacheIgnoreNoLastMod Off |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
Normalement, les documents qui ne possèdent pas de date de
+ dernière modification ne sont pas mis en cache. Dans certaines
+ circonstances, la date de dernière modification est supprimée (au
+ cours des traitements liés à mod_include par
+ exemple), ou n'existe tout simplement pas. La directive
+ CacheIgnoreNoLastMod permet de spécifier si
+ les documents ne possèdant pas de date de dernière modification
+ doivent être mis en cache, même sans date de dernière modification.
+ Si le document ne possède ni date d'expiration, ni date de dernière
+ modification, la valeur spécifiée par la directive
+ CacheDefaultExpire servira à générer une date
+ d'expiration.
+
+ CacheIgnoreNoLastMod On
+
CacheIgnoreQueryString Directive
+| Description: | Ignore la chaîne de paramètres lors de la mise en +cache |
|---|---|
| Syntaxe: | CacheIgnoreQueryString On|Off |
| Défaut: | CacheIgnoreQueryString Off |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
Normalement, les requêtes comportant une chaîne de paramètres
+ sont mises en cache séparément si leurs chaînes de paramètres
+ diffèrent.
+ En accord avec la RFC 2616/13.9, cette mise en cache n'est effectuée
+ séparément que si une date d'expiration est spécifiée. La directive
+ CacheIgnoreQueryString permet la mise en
+ cache de requêtes même si aucune date d'expiration est spécifiée, et
+ de renvoyer une réponse depuis la cache même si les chaînes de
+ paramètres diffèrent. Du point de vue du cache, la requête est
+ traitée comme si elle ne possèdait pas de chaîne de paramètres
+ lorsque cette directive est activée.
+ CacheIgnoreQueryString On
+
CacheIgnoreURLSessionIdentifiers Directive
+| Description: | Ignore les identifiants de session définis encodés dans +l'URL lors de la mise en cache + |
|---|---|
| Syntaxe: | CacheIgnoreURLSessionIdentifiers identifiant
+[identifiant] ... |
| Défaut: | CacheIgnoreURLSessionIdentifiers None |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
Certaines applications encodent l'identifiant de session dans + l'URL comme dans l'exemple suivant : +
+-
+
/une-application/image.gif;jsessionid=123456789
+ /une-application/image.gif?PHPSESSIONID=12345678
+
Ceci implique la mise en cache des ressources séparément pour
+ chaque session, ce qui n'est en général pas souhaité. La directive
+ CacheIgnoreURLSessionIdentifiers permet de
+ définir une liste d'identifiants qui seront supprimés de la clé
+ utilisée pour identifier une entité dans le cache, de façon à ce que
+ les ressources ne soient pas stockées séparément pour chaque
+ session.
+
CacheIgnoreURLSessionIdentifiers None vide la liste
+ des identifiants ignorés. Autrement, chaque identifiant spécifié est
+ ajouté à la liste.
Exemple 1
+ CacheIgnoreURLSessionIdentifiers jsessionid
+
Exemple 2
+ CacheIgnoreURLSessionIdentifiers None
+
CacheLastModifiedFactor Directive
+| Description: | Le facteur utilisé pour générer une date d'expiration en +fonction de la date de dernière modification. |
|---|---|
| Syntaxe: | CacheLastModifiedFactor flottant |
| Défaut: | CacheLastModifiedFactor 0.1 |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
Si un document ne possède pas de date d'expiration, elle peut
+ être calculée en fonction de la date de dernière modification, si
+ elle existe. La directive
+ CacheLastModifiedFactor permet de spécifier
+ un facteur à utiliser pour la génération de cette date
+ d'expiration au sein de la formule suivante :
+
+ délai-expiration = durée-depuis-date-dernière-modification *
+ facteur
+ date-expiration = date-courante + délai-expiration
+
+ Par exemple, si la dernière modification du document date de 10
+ heures, et si facteur a pour valeur 0.1, le délai
+ d'expiration sera de 10*0.1 = 1 heure. Si l'heure courante est
+ 3:00pm, la date d'expiration calculée sera 3:00pm + 1 heure =
+ 4:00pm.
+
+ Si le délai d'expiration est supérieur à celui spécifié par la
+ directive CacheMaxExpire, c'est ce dernier
+ qui l'emporte.
+ CacheLastModifiedFactor 0.5
+
CacheLock Directive
+| Description: | Active la protection contre les tempêtes de requêtes. |
|---|---|
| Syntaxe: | CacheLock on|off |
| Défaut: | CacheLock off |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheLock active la protection
+ contre les tempêtes de requêtes pour l'espace d'adressage donné.
La configuration minimale pour activer le verrouillage contre les + tempêtes de requêtes dans le répertoire temp par défaut du système est + la suivante :
+ +
+ # Active le verrouillage du cache
+ CacheLock on
+
CacheLockMaxAge Directive
+| Description: | Définit la durée de vie maximale d'un verrou de cache. |
|---|---|
| Syntaxe: | CacheLockMaxAge entier |
| Défaut: | CacheLockMaxAge 5 |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheLockMaxAge permet de
+ spécifier la durée de vie maximale d'un verrou de cache.
Un verrou plus ancien que cette valeur exprimée en secondes sera + ignoré, et la prochaine requête entrante sera alors en mesure de + recréer le verrou. Ce mécanisme permet d'éviter les mises à jour trop + longues initiées par des clients lents.
+ + +CacheLockPath Directive
+| Description: | Définit le répertoire des verrous. |
|---|---|
| Syntaxe: | CacheLockPath répertoire |
| Défaut: | CacheLockPath /tmp/mod_cache-lock |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheLockPath permet de
+ spécifier le répertoire dans lequel les verrous sont créés. Par
+ défaut, c'est le répertoire temporaire du système qui est utilisé. Les
+ verrous sont des fichiers vides qui n'existent que pour les URLs
+ périmées en cours de mise à jour, et consomment donc bien moins de
+ ressources que le traditionnel cache sur disque.
CacheMaxExpire Directive
+| Description: | La durée maximale en secondes de mise en cache d'un +document |
|---|---|
| Syntaxe: | CacheMaxExpire secondes |
| Défaut: | CacheMaxExpire 86400 (une journée) |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheMaxExpire permet de
+ spécifier le nombre maximum de secondes pendant lequel les documents
+ HTTP suceptibles d'être mis en cache seront conservés sans vérifier
+ leur contenu sur le serveur d'origine. Ce nombre de secondes
+ correspond donc à la durée maximale pendant laquelle un document ne
+ sera pas à jour. L'utilisation de cette valeur maximale est forcée,
+ même si le document possède une date d'expiration.
+ CacheMaxExpire 604800
+
CacheMinExpire Directive
+| Description: | La durée minimale en secondes de mise en cache d'un +document |
|---|---|
| Syntaxe: | CacheMinExpire secondes |
| Défaut: | CacheMinExpire 0 |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheMaxExpire permet de
+ spécifier le nombre maximum de secondes pendant lequel les documents
+ HTTP suceptibles d'être mis en cache seront conservés sans vérifier
+ leur contenu sur le serveur d'origine. Elle n'est prise en compte
+ que dans le cas où le document ne possède aucune date d'expiration
+ valide.
+ CacheMinExpire 3600
+
CacheQuickHandler Directive
+| Description: | Exécute le cache à partir d'un gestionnaire rapide. |
|---|---|
| Syntaxe: | CacheQuickHandler on|off |
| Défaut: | CacheQuickHandler on |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheQuickHandler permet de contrôler
+ la phase au cours de laquelle la mise en cache est effectuée.
Avec la configuration par défaut, le cache agit au cours de la + phase du gestionnaire rapide. Cette phase court-circuite la majorité + des traitements du serveur, et constitue le mode d'opération le plus + performant pour un serveur typique. Le cache + s'incruste devant le serveur, et la majorité des + traitements du serveur est court-circuitée.
+ +Lorsque cette directive est définie à off, le cache agit comme un + gestionnaire normal, et est concerné par toutes les phases de + traitement d'une requête. Bien que ce mode soit moins performant que + le mode par défaut, il permet d'utiliser le cache dans les cas où un + traitement complet de la requête est nécessaire, comme par exemple + lorsque le contenu est soumis à autorisation.
+ +
+ # Exécute le cache comme un gestionnaire normal
+ CacheQuickHandler off
+
Lorsque le gestionnaire rapide est désactivé, l'administrateur a + aussi la possibilité de choisir avec précision le point de la chaîne + de filtrage où la mise en cache sera effectuée, en utilisant le + filtre CACHE.
+ +
+ # Mise en cache du contenu avant l'intervention de mod_include et
+ # mod_deflate
+ CacheQuickHandler off
+ AddOutputFilterByType CACHE;INCLUDES;DEFLATE text/html
+
Si le filtre CACHE est spécifié plusieurs fois, c'est la dernière + instance qui sera prise en compte.
+ + +CacheStoreNoStore Directive
+| Description: | Tente de mettre en cache les requêtes ou réponses dont +l'entête Cache-Control: a pour valeur no-store. |
|---|---|
| Syntaxe: | CacheStoreNoStore On|Off |
| Défaut: | CacheStoreNoStore Off |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
Normalement, les requêtes ou réponses dont l'en-tête
+ Cache-Control: a pour valeur no-store ne sont pas stockées dans le
+ cache. La directive CacheStoreNoCache permet
+ de modifier ce comportement. Si
+ CacheStoreNoCache est définie à On, le
+ serveur tente de mettre la ressource en cache même si elle contient
+ des en-têtes ayant pour valeur no-store. Les ressources
+ nécessitant une autorisation ne sont jamais mises en
+ cache.
+ CacheStoreNoStore On
+
Avertissement :
+ Selon la RFC 2616, la valeur d'en-tête no-store est censée + "prévenir la suppression ou la rétention par inadvertance + d'informations sensibles (par exemple, sur des bandes de + sauvegarde)". Autrement dit, l'activation de la directive +CacheStoreNoCache pourrait provoquer le
+ stockage d'informations sensibles dans le cache. Vous avez donc
+ été prévenus.
+ Voir aussi
+ +CacheStorePrivate Directive
+| Description: | Tente de mettre en cache des réponses que le serveur a +marquées comme privées |
|---|---|
| Syntaxe: | CacheStorePrivate On|Off |
| Défaut: | CacheStorePrivate Off |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
Normalement, les réponse comportant un en-tête Cache-Control:
+ dont la valeur est private ne seront pas stockées dans le cache. La
+ directive CacheStorePrivate permet de
+ modifier ce comportement. Si
+ CacheStorePrivate est définie à On, le
+ serveur tentera de mettre la ressource en cache, même si elle
+ contient des en-têtes ayant pour valeur private. Les ressources
+ nécessitant une autorisation ne sont jamais mises en
+ cache.
+ CacheStorePrivate On
+
Avertissement :
+ Cette directive autorise la mise en cache même si le serveur + indique que la ressource ne doit pas être mise en cache. Elle + n'est de ce fait appropriée que dans le cas d'un cache + 'privé'. +Voir aussi
+ +-
+
mod_disk_cache
+ - implémente un gestionnaire de stockage sur disque. +
Les contenus sont stockés dans le cache et extraits de ce dernier + en utilisant une clé à base d'URI. Un contenu dont l'accès est + protégé ne sera pas mis en cache.
+Pour de plus amples détails, une description, et des exemples, + reportez-vous au Guide de la mise en + cache.
++ # Exemple de configuration du cache
+ #
+ LoadModule cache_module modules/mod_cache.so
+
+ <IfModule mod_cache.c>
+
+ <IfModule mod_disk_cache.c>
+
+ CacheEnable disk /
+ CacheDirLevels 5
+ CacheDirLength 3
+
+
+ # Lorsqu'on sert de mandataire, on ne met pas en cache la liste + # des mises à jour de sécurité
+ CacheDisable http://security.update.server/update-list/
+
Lorsqu'une entrée du cache est périmée,
Un court mais non négligeable laps de temps existe entre le moment + où l'entrée du cache est périmée, et le moment où elle est mise à + jour. Sur un serveur fortement chargé, un certain nombre de requêtes + peut arriver pendant ce laps de temps, et provoquer une + tempête de requêtes susceptibles de saturer le + processus d'arrière-plan de manière soudaine et imprédictible.
+Pour contenir cette tempête, on peut utiliser la directive
+
Lorsqu'une entité est mise en cache pour la première fois, un + verrou est créé pour cette entité jusqu'à ce que la réponse ait été + entièrement mise en cache. Pendant la durée de vie du verrou, le + cache va empêcher une seconde tentative de mise en cache de la même + entité. Bien que cela ne suffise pas à contenir la tempête de + requêtes, toute tentative de mettre en cache la même entité + plusieurs fois simultanément est stoppée. +
+Lorsqu'une entrée atteint la limite de sa durée de vie, et + devient par conséquent périmée, un verrou est créé pour cette entité + jusqu'à ce que la réponse ait été soit confirmée comme encore + valide, soit remplacée par le processus d'arrière-plan. Pendant la + durée de vie du verrou, une seconde requête entrante va provoquer le + renvoi de la donnée périmée, et la tempête de requêtes sera + contenue.
+Les verrous ne sont utilisés qu'à titre + indicatif pour enjoindre le cache à être plus coopératif + avec les serveurs d'arrière-plan, et il est possible de passer outre + si nécessaire. Si le client envoie une requête contenant un en-tête + Cache-Control imposant un nouveau téléchargement de l'entité, tout + verrou éventuel sera ignoré, la requête du client sera honorée + immédiatement, et l'entrée du cache mise à jour.
+ +Comme mécanisme de sécurité supplémentaire, la durée de vie
+ maximale des verrous est configurable. Lorsque cette limite est
+ atteinte, le verrou est supprimé et une autre requête peut alors en
+ créer un nouveau. Cette durée de vie peut être définie via la
+ directive
+ # Active le verrouillage du cache
+ #
+ <IfModule mod_cache.c>
+
+ CacheLockPath /tmp/mod_cache-lock
+ CacheLockMaxAge 5
+
Dans son mode de fonctionnement par défaut, le cache s'exécute sous + la forme d'un gestionnaire rapide, court-circuitant la majorité des + traitements du serveur et fournissant ainsi une mise en cache + possédant les plus hautes performances disponibles.
+ +Dans ce mode, le cache s'incruste devant le + serveur, comme si un mandataire de mise en cache indépendant RFC2616 + était placé devant ce dernier.
+ +Bien que que ce mode offre les meilleures performances, les + administrateurs peuvent souhaiter, dans certaines circonstances, + effectuer des traitements sur la requête après que cette dernière ait + été mise en cache, comme ajouter du contenu personnalisé à la page + mise en cache, ou appliquer des restrictions d'autorisations au + contenu. Pour y parvenir, l'administrateur sera alors souvent forcé de + placer des serveurs mandataires inverses indépendants soit derrière, + soit devant le serveur de mise en cache.
+ +Pour résoudre ce problème, la directive
En outre, l'administrateur peut éventuellement spécifier le + point précis dans la chaîne de filtrage où devra + intervenir la mise en cache en ajoutant le filtre + CACHE à la chaîne de filtrage en sortie.
+ +Par exemple, pour mettre en cache le contenu avant d'appliquer une + compression à la réponse, placez le filtre CACHE + avant le filtre DEFLATE comme dans l'exemple suivant + :
+ ++ CacheQuickHandler off
+ AddOutputFilterByType CACHE;DEFLATE text/plain
+
Une autre possibilité consiste à mettre en cache le contenu avant
+ l'ajout de contenu personnalisé via
+ CacheQuickHandler off
+ AddOutputFilterByType CACHE;INCLUDES;DEFLATE text/html
+
Vous pouvez insérer le filtre CACHE en tout point
+ de la chaîne de filtrage. Dans l'exemple suivant, le contenu est mis
+ en cache après avoir été interprété par
+ CacheQuickHandler off
+ AddOutputFilterByType INCLUDES;CACHE;DEFLATE text/html
+
La directive disk,
Si les différentes directives
En fonctionnement du type serveur mandataire direct, chaîne + URL peut aussi être utilisé pour spécifier des sites distants + et des protocoles de mandat pour lesquels la mise en cache devra + être activée.
+ ++ CacheEnable disk /
+ # Mise en cache des URLs FTP mandatées
+ CacheEnable disk ftp://
+ # Mise en cache des contenus situés dans www.apache.org
+ CacheEnable disk http://www.apache.org/
+
Un nom d'hôte commençant par un caractère "*" + correspondra à tout nom d'hôte se terminant par le suffixe + considéré. Un nom d'hôte commençant par un caractère + "." correspondra à tout nom d'hôte contenant le + composant de nom de domaine qui suit ce caractère.
+ ++ CacheEnable disk http://*apache.org/
+ # Correspond à www.apache.org, mais pas à fooapache.org
+ CacheEnable disk http://.apache.org/
+
Depuis la version 2.2.12, on peut définir la variable
+ d'environnement no-cache pour une définition plus fine
+ des ressources à mettre en cache.
La directive
Si la directive se trouve à l'intérieur d'une section
+ CacheDisable on
+ </Location>
+
Avec les versions 2.2.12 et ultérieures, on peut définir la
+ variable d'environnement no-cache pour une définition
+ plus fine des ressources à mettre en cache.
La directive
La directive
La directive
Normalement, les documents qui ne possèdent pas de date de
+ dernière modification ne sont pas mis en cache. Dans certaines
+ circonstances, la date de dernière modification est supprimée (au
+ cours des traitements liés à
Normalement, les requêtes contenant des en-têtes tels que
+ Cache-Control: no-cache ou Pragma: no-cache ne sont pas servies
+ depuis le cache. La directive
+
Normalement, les requêtes comportant une chaîne de paramètres
+ sont mises en cache séparément si leurs chaînes de paramètres
+ diffèrent.
+ En accord avec la RFC 2616/13.9, cette mise en cache n'est effectuée
+ séparément que si une date d'expiration est spécifiée. La directive
+
Si un document ne possède pas de date d'expiration, elle peut
+ être calculée en fonction de la date de dernière modification, si
+ elle existe. La directive
+ délai-expiration = durée-depuis-date-dernière-modification *
+ facteur
+ date-expiration = date-courante + délai-expiration
+
+ Par exemple, si la dernière modification du document date de 10
+ heures, et si facteur a pour valeur 0.1, le délai
+ d'expiration sera de 10*0.1 = 1 heure. Si l'heure courante est
+ 3:00pm, la date d'expiration calculée sera 3:00pm + 1 heure =
+ 4:00pm.
+
+ Si le délai d'expiration est supérieur à celui spécifié par la
+ directive
En accord avec la RFC 2616, les en-têtes HTTP hop-by-hop ne sont
+ pas stockés dans le cache. Les en-têtes HTTP suivant sont des
+ en-têtes hop-by-hop, et en tant que tels, ne sont en aucun
+ cas stockés dans le cache, quelle que soit la définition de la
+ directive
-
+
Connection
+ Keep-Alive
+ Proxy-Authenticate
+ Proxy-Authorization
+ TE
+ Trailers
+ Transfer-Encoding
+ Upgrade
+
La directive
La directive None.
Expires, ne sont pas stockés suite à la définition
+ d'une directive Certaines applications encodent l'identifiant de session dans + l'URL comme dans l'exemple suivant : +
+-
+
/une-application/image.gif;jsessionid=123456789
+ /une-application/image.gif?PHPSESSIONID=12345678
+
Ceci implique la mise en cache des ressources séparément pour
+ chaque session, ce qui n'est en général pas souhaité. La directive
+
CacheIgnoreURLSessionIdentifiers None vide la liste
+ des identifiants ignorés. Autrement, chaque identifiant spécifié est
+ ajouté à la liste.
Normalement, les réponse comportant un en-tête Cache-Control:
+ dont la valeur est private ne seront pas stockées dans le cache. La
+ directive
Normalement, les requêtes ou réponses dont l'en-tête
+ Cache-Control: a pour valeur no-store ne sont pas stockées dans le
+ cache. La directive
La directive
La configuration minimale pour activer le verrouillage contre les + tempêtes de requêtes dans le répertoire temp par défaut du système est + la suivante :
+ ++ CacheLock on
+
La directive
La directive
Un verrou plus ancien que cette valeur exprimée en secondes sera + ignoré, et la prochaine requête entrante sera alors en mesure de + recréer le verrou. Ce mécanisme permet d'éviter les mises à jour trop + longues initiées par des clients lents.
+ +La directive
Avec la configuration par défaut, le cache agit au cours de la + phase du gestionnaire rapide. Cette phase court-circuite la majorité + des traitements du serveur, et constitue le mode d'opération le plus + performant pour un serveur typique. Le cache + s'incruste devant le serveur, et la majorité des + traitements du serveur est court-circuitée.
+ +Lorsque cette directive est définie à off, le cache agit comme un + gestionnaire normal, et est concerné par toutes les phases de + traitement d'une requête. Bien que ce mode soit moins performant que + le mode par défaut, il permet d'utiliser le cache dans les cas où un + traitement complet de la requête est nécessaire, comme par exemple + lorsque le contenu est soumis à autorisation.
+ ++ CacheQuickHandler off
+
Lorsque le gestionnaire rapide est désactivé, l'administrateur a + aussi la possibilité de choisir avec précision le point de la chaîne + de filtrage où la mise en cache sera effectuée, en utilisant le + filtre CACHE.
+ ++ CacheQuickHandler off
+ AddOutputFilterByType CACHE;INCLUDES;DEFLATE text/html
+
Si le filtre CACHE est spécifié plusieurs fois, c'est la dernière + instance qui sera prise en compte.
+ +always
may be needed to influence headers set by some internal modules even for
successful responses, and is always needed to affect non-2xx
- responses such as redirects or client errors.
+ responses such as redirects or client errors.
The action it performs is determined by the second argument. This can be one of the following values:
diff --git a/docs/manual/mod/mod_headers.xml.ja b/docs/manual/mod/mod_headers.xml.ja index 12a2cd6ec8..6c73c351a6 100644 --- a/docs/manual/mod/mod_headers.xml.ja +++ b/docs/manual/mod/mod_headers.xml.ja @@ -1,7 +1,7 @@ - + +