From 11e5f75aaaafb3aca1f835beb142eb0dab292f21 Mon Sep 17 00:00:00 2001 From: Vincent Deffontaines Date: Sat, 16 Nov 2013 14:45:37 +0000 Subject: [PATCH] Completing r1542515, where accents were not converted git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1542516 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/compliance.xml.fr | 430 +++++++++++++++++----------------- 1 file changed, 215 insertions(+), 215 deletions(-) diff --git a/docs/manual/compliance.xml.fr b/docs/manual/compliance.xml.fr index 6a342740fc..0e5d2bbce9 100644 --- a/docs/manual/compliance.xml.fr +++ b/docs/manual/compliance.xml.fr @@ -1,4 +1,4 @@ - + @@ -24,24 +24,24 @@ - Conformité au protocole HTTP + Conformité au protocole HTTP -

Ce document décrit le mécanisme utilisé pour définir une - politique de conformité au protocole HTTP pour un espace d'URL au - niveau des serveurs d'origine ou des application sous-jacentes à cet +

Ce document décrit le mécanisme utilisé pour définir une + politique de conformité au protocole HTTP pour un espace d'URL au + niveau des serveurs d'origine ou des application sous-jacentes à cet espace d'URL.

-

Chaque politique de conformité est décrite ci-dessous à - destination de tous ceux qui ont reçu un message d'erreur suite à un - rejet en provenance d'une politique, et ont donc besoin de savoir à +

Chaque politique de conformité est décrite ci-dessous à + destination de tous ceux qui ont reçu un message d'erreur suite à un + rejet en provenance d'une politique, et ont donc besoin de savoir à quoi est du ce rejet et ce qu'ils doivent faire pour corriger l'erreur.

 Filtres
- Imposer la conformité au protocole HTTP dans Apache 2 + Imposer la conformité au protocole HTTP dans Apache 2 mod_policy @@ -60,73 +60,73 @@

Le protocole HTTP applique le principe de - robustesse décrit dans la décrit dans la RFC1122, et stipulant - "Soyez libéral pour ce que vous acceptez, conservateur pour + "Soyez libéral pour ce que vous acceptez, conservateur pour ce que vous envoyez". Selon ce principe, les clients HTTP - vont compenser en corrigeant les réponses incorrectes ou mal - configurées, ou ne pouvant pas être mises en cache.

- -

Comme un site web est configuré pour faire face à un trafic - toujours grandissant, des applications mal configurées ou non - optimisées ou certaines configurations de serveur peuvent menacer la stabilité - et l'évolutivité du site web, ainsi que les coûts d'hébergement qui - y sont associés. L'évolution d'un site web pour faire face à une - complexité croissante de sa configuration accroît les - difficultés rencontrées pour détecter et enregistrer les espaces - d'URL mal configurés pour un serveur donné.

- -

De ce fait, un point peut être atteint où le principe - "conservateur pour ce que vous envoyez" doit être imposé par + vont compenser en corrigeant les réponses incorrectes ou mal + configurées, ou ne pouvant pas être mises en cache.

+ +

Comme un site web est configuré pour faire face à un trafic + toujours grandissant, des applications mal configurées ou non + optimisées ou certaines configurations de serveur peuvent menacer la stabilité + et l'évolutivité du site web, ainsi que les coûts d'hébergement qui + y sont associés. L'évolution d'un site web pour faire face à une + complexité croissante de sa configuration accroît les + difficultés rencontrées pour détecter et enregistrer les espaces + d'URL mal configurés pour un serveur donné.

+ +

De ce fait, un point peut être atteint où le principe + "conservateur pour ce que vous envoyez" doit être imposé par l'administrateur du serveur.

Le module mod_policy fournit un jeu de filtres - qui peuvent être appliqués à un serveur, permettant de tester - explicitement les points clé du protocle HTTP, et de journaliser en - tant qu'avertissements les réponses non conformes, ou même de + qui peuvent être appliqués à un serveur, permettant de tester + explicitement les points clé du protocle HTTP, et de journaliser en + tant qu'avertissements les réponses non conformes, ou même de simplement les rejeter avec un code d'erreur. Chaque filtre peut - être appliqué séparément, permettant à l'administrateur de choisir - quelles politiques de conformité doivent être imposées en fonction + être appliqué séparément, permettant à l'administrateur de choisir + quelles politiques de conformité doivent être imposées en fonction de l'environnement.

-

Les filtres peuvent être mis en place dans des environnements de - test ou de simulation à destination des développeurs d'applications - et de sites web, ou s'appliquer à des serveurs en production pour - protéger l'infrastructure de systèmes en dehors du contrôle direct +

Les filtres peuvent être mis en place dans des environnements de + test ou de simulation à destination des développeurs d'applications + et de sites web, ou s'appliquer à des serveurs en production pour + protéger l'infrastructure de systèmes en dehors du contrôle direct de l'administrateur.

-

-

Dans l'exemple ci-dessus, un serveur Apache httpd a été intercalé +

Dans l'exemple ci-dessus, un serveur Apache httpd a été intercalé entre le serveur d'applications et l'internet au sens large, et - configuré pour mettre en cache les réponses en provenance du serveur - d'applications. Les filtres de mod_policy ont été - ajoutés pour imposer le support de la mise en cache de contenu et - des requêtes conditionnelles, assurant ainsi que + configuré pour mettre en cache les réponses en provenance du serveur + d'applications. Les filtres de mod_policy ont été + ajoutés pour imposer le support de la mise en cache de contenu et + des requêtes conditionnelles, assurant ainsi que mod_cache et les caches publics de l'internet - seront pleinement capables de mettre en cache le contenu créé avec - efficacité par le serveur d'applications.

+ seront pleinement capables de mettre en cache le contenu créé avec + efficacité par le serveur d'applications.

- + "Imposer la conformité au protocole HTTP pour un serveur statique"/>

Dans l'exemple plus simple ci-dessus, un serveur statique qui - sert du contenu ayant une forte probabilité d'être mis en cache, - se voit appliqué un jeu de règles afin de + sert du contenu ayant une forte probabilité d'être mis en cache, + se voit appliqué un jeu de règles afin de s'assurer que sa configuration respecte un niveau minimum de - conformité au protocole HTTP.

+ conformité au protocole HTTP.

- Politique des requêtes conditionnelles + Politique des requêtes conditionnelles mod_policy @@ -136,81 +136,81 @@ -

Cette politique sera rejetée si le serveur ne répond pas à une - requête conditionnelle avec le code d'état approprié.

+

Cette politique sera rejetée si le serveur ne répond pas à une + requête conditionnelle avec le code d'état approprié.

-

C'est grâce aux requêtes conditionnelles qu'un cache HTTP peut - rafraîchir un contenu périmé, et en particulier dans le cas des - contenus à durée de validité courte, l'absence de support des - requêtes conditionnelles peut augmenter la charge du serveur.

+

C'est grâce aux requêtes conditionnelles qu'un cache HTTP peut + rafraîchir un contenu périmé, et en particulier dans le cas des + contenus à durée de validité courte, l'absence de support des + requêtes conditionnelles peut augmenter la charge du serveur.

-

Plus particulièrement, la présence d'une des en-têtes suivantes - dans la requête rend cette dernière conditionnelle :

+

Plus particulièrement, la présence d'une des en-têtes suivantes + dans la requête rend cette dernière conditionnelle :

If-Match
-
Si l'ETag fourni dans l'en-tête If-Match ne - correspond pas à l'ETag de la réponse, le serveur doit renvoyer un +
Si l'ETag fourni dans l'en-tête If-Match ne + correspond pas à l'ETag de la réponse, le serveur doit renvoyer un code d'erreur 412 Precondition Failed. Vous trouverez - tous les détails du traitement d'un en-tête If-Match + tous les détails du traitement d'un en-tête If-Match dans la RFC2616 section 14.24.
If-None-Match
-
Si l'ETag fourni dans l'en-tête If-None-Match - correspond à l'ETag de la réponse, le serveur doit renvoyer soit - 304 Not Modified pour les requêtes GET/HEAD, soit - 412 Precondition Failed pour les autres méthodes. Vous trouverez - tous les détails du traitement d'un en-tête +
Si l'ETag fourni dans l'en-tête If-None-Match + correspond à l'ETag de la réponse, le serveur doit renvoyer soit + 304 Not Modified pour les requêtes GET/HEAD, soit + 412 Precondition Failed pour les autres méthodes. Vous trouverez + tous les détails du traitement d'un en-tête If-None-Match dans la RFC2616 section 14.26.
If-Modified-Since
-
Si la date fournie dans l'en-tête If-Modified-Since - est plus ancienne que celle de l'en-tête Last-Modified - de la réponse, le serveur doit renvoyer 304 Not Modified. Vous trouverez - tous les détails du traitement d'un en-tête +
Si la date fournie dans l'en-tête If-Modified-Since + est plus ancienne que celle de l'en-tête Last-Modified + de la réponse, le serveur doit renvoyer 304 Not Modified. Vous trouverez + tous les détails du traitement d'un en-tête If-Modified-Since dans la RFC2616 section 14.25.
If-Unmodified-Since
-
Si la date fournie dans l'en-tête - If-Unmodified-Since est plus récente que celle de - l'en-tête Last-Modified de la réponse, le serveur doit +
Si la date fournie dans l'en-tête + If-Unmodified-Since est plus récente que celle de + l'en-tête Last-Modified de la réponse, le serveur doit renvoyer 412 Precondition Failed. Vous trouverez - tous les détails du traitement d'un en-tête + tous les détails du traitement d'un en-tête If-Unmodified-Since dans la RFC2616 section 14.28.
If-Range
-
Si l'ETag fourni dans l'en-tête If-Range correspond - à l'ETag ou à l'en-tête Last-Modified de la réponse, et si un - en-tête Range valide est présent, le serveur doit +
Si l'ETag fourni dans l'en-tête If-Range correspond + à l'ETag ou à l'en-tête Last-Modified de la réponse, et si un + en-tête Range valide est présent, le serveur doit renvoyer 206 Partial Response. Vous trouverez - tous les détails du traitement d'un en-tête If-Range + tous les détails du traitement d'un en-tête If-Range dans la RFC2616 section 14.27.
-

Si la réponse est considérée comme ayant réussi (une réponse - 2xx), alors qu'elle était conditionnelle et qu'une des réponses - ci-dessus était attendue à la place, cette politique sera rejetée. - Les réponses qui indiquent une redirection ou une erreur de toute - sorte (3xx, 4xx, 5xx) seront ignorées de cette politique.

+

Si la réponse est considérée comme ayant réussi (une réponse + 2xx), alors qu'elle était conditionnelle et qu'une des réponses + ci-dessus était attendue à la place, cette politique sera rejetée. + Les réponses qui indiquent une redirection ou une erreur de toute + sorte (3xx, 4xx, 5xx) seront ignorées de cette politique.

-

Cette politique est implémentée par le filtre +

Cette politique est implémentée par le filtre POLICY_CONDITIONAL.

- Politique de gestion de l'en-tête Content-Length + Politique de gestion de l'en-tête Content-Length mod_policy @@ -220,54 +220,54 @@ -

Cette politique sera rejetée si la réponse du serveur ne contient pas d'en-tête +

Cette politique sera rejetée si la réponse du serveur ne contient pas d'en-tête Content-Length explicite.

-

De nombreuses méthodes pour déterminer la taille d'un - corps de réponse sont décrites dans la De nombreuses méthodes pour déterminer la taille d'un + corps de réponse sont décrites dans la RFC2616 section 4.4 Message Length.

-

Lorsque l'en-tête Content-Length est présente, la - taille du corps est déclarée au début de la réponse. Si cette +

Lorsque l'en-tête Content-Length est présente, la + taille du corps est déclarée au début de la réponse. Si cette information est manquante, un cache HTTP pourrait choisir d'ignorer - la réponse, car il ne pourrait pas déterminer a priori si la réponse - reste dans les limites définies du cache.

+ la réponse, car il ne pourrait pas déterminer a priori si la réponse + reste dans les limites définies du cache.

-

Pour indiquer la fin de la réponse au client sans que ce dernier - ait à en connaître la taille au préalable, HTTP/1.1 propose - l'en-tête Transfer-Encoding comme une alternative à +

Pour indiquer la fin de la réponse au client sans que ce dernier + ait à en connaître la taille au préalable, HTTP/1.1 propose + l'en-tête Transfer-Encoding comme une alternative à Content-Length. Cependant, lors du traitement de - requêtes HTTP/1.0, et si l'en-tête Content-Length est - absente, le seul mécanisme dont dispose le serveur pour indiquer la - fin de la requête consiste à couper la connexion. Dans un - environnement contenant des répartiteurs de charge, cela peut - court-circuiter le mécanisme des connexions persistantes + requêtes HTTP/1.0, et si l'en-tête Content-Length est + absente, le seul mécanisme dont dispose le serveur pour indiquer la + fin de la requête consiste à couper la connexion. Dans un + environnement contenant des répartiteurs de charge, cela peut + court-circuiter le mécanisme des connexions persistantes (keepalive).

-

Si la réponse est considérée comme réussie (une réponse 2xx) et - possède un corps (ce qui exclut les réponses 204 No - Content), et si l'en-tête Content-Length est - absente, la réponse sera rejetée. Aucune réponse indiquant une +

Si la réponse est considérée comme réussie (une réponse 2xx) et + possède un corps (ce qui exclut les réponses 204 No + Content), et si l'en-tête Content-Length est + absente, la réponse sera rejetée. Aucune réponse indiquant une redirection ou une erreur de toute nature (3xx, 4xx, 5xx) n'est prise en compte par cette politique.

Notez que certains modules comme - mod_proxy ajoutent leur propre en-tête - Content-Length sous réserve que la réponse où cette - en-tête est absente soit suffisamment courte pour que le module ait - pu la lire en une seule passe. De ce fait, des réponses courtes pourront - être acceptées par la politique, alors que d'autres plus longues - seront rejetées pour la même URL. - -

Cette politique est implémentée par le filtre + mod_proxy ajoutent leur propre en-tête + Content-Length sous réserve que la réponse où cette + en-tête est absente soit suffisamment courte pour que le module ait + pu la lire en une seule passe. De ce fait, des réponses courtes pourront + être acceptées par la politique, alors que d'autres plus longues + seront rejetées pour la même URL. + +

Cette politique est implémentée par le filtre POLICY_LENGTH.

- Politique de filtrage de l'en-tête Content-Type + Politique de filtrage de l'en-tête Content-Type mod_policy @@ -277,23 +277,23 @@ -

Cette politique sera rejetée si la réponse du serveur ne contient pas d'en-tête +

Cette politique sera rejetée si la réponse du serveur ne contient pas d'en-tête Content-Type explicite et valide du point de vue de la - syntaxe, correspondant au modèle défini par le serveur.

+ syntaxe, correspondant au modèle défini par le serveur.

-

Le type de media du corps est placé dans une en-tête - Content-Type dont le format est décrit en détail dans +

Le type de media du corps est placé dans une en-tête + Content-Type dont le format est décrit en détail dans la RFC2616 section 3.7 Media Types.

-

Une en-tête Content-Type dont la syntaxe est valide +

Une en-tête Content-Type dont la syntaxe est valide sera du style :

Content-Type: text/html; charset=iso-8859-1 -

Exemples d'en-têtes Content-Type non valides :

+

Exemples d'en-têtes Content-Type non valides :

# invalide
@@ -302,8 +302,8 @@ Content-Type: -

L'administrateur peut restreindre la politique à un ou plusieurs - types spécifiques, ou utiliser des caractères génériques comme +

L'administrateur peut restreindre la politique à un ou plusieurs + types spécifiques, ou utiliser des caractères génériques comme */*.

Cette politique est mise en oeuvre par le filtre @@ -322,71 +322,71 @@ -

Cette politique era rejetée si la réponse du serveur ne contient pas d'en-tête - Content-Length explicite, ou d'en-tête - Transfer-Encoding défini à chunked.

+

Cette politique era rejetée si la réponse du serveur ne contient pas d'en-tête + Content-Length explicite, ou d'en-tête + Transfer-Encoding défini à chunked.

-

De nombreuses manières pour déterminer la taille d'un - corps de réponse sont décrites dans la De nombreuses manières pour déterminer la taille d'un + corps de réponse sont décrites dans la RFC2616 section 4.4 Message Length.

-

Pour indiquer la fin de la réponse au client sans que ce dernier - ait à en connaître la taille au préalable, HTTP/1.1 propose - l'en-tête Transfer-Encoding comme une alternative à +

Pour indiquer la fin de la réponse au client sans que ce dernier + ait à en connaître la taille au préalable, HTTP/1.1 propose + l'en-tête Transfer-Encoding comme une alternative à Content-Length. Cependant, lors du traitement de - requêtes HTTP/1.0, et si l'en-tête Content-Length est - absent, le seul mécanisme dont dispose le serveur pour indiquer la - fin de la requête consiste à couper la connexion. Dans un - environnement contenant des répartiteurs de charge, cela peut - court-circuiter le mécanisme des connexions persistantes + requêtes HTTP/1.0, et si l'en-tête Content-Length est + absent, le seul mécanisme dont dispose le serveur pour indiquer la + fin de la requête consiste à couper la connexion. Dans un + environnement contenant des répartiteurs de charge, cela peut + court-circuiter le mécanisme des connexions persistantes (keepalive).

-

En particulier, les règles suivantes sont appliquées :

+

En particulier, les règles suivantes sont appliquées :

Si
-
cette connexion n'est pas marquée en erreur ;
+
cette connexion n'est pas marquée en erreur ;
et
le client n'attend pas 100-continue ;
et
-
le code de statut de la réponse ne nécessite pas de fermeture de connexion ;
+
le code de statut de la réponse ne nécessite pas de fermeture de connexion ;
et
-
le corps de la réponse a une taille définie suite au code de - statut 304 ou 204, la méthode de requête est HEAD, un en-tête - Content-Length ou Transfer-Encoding: chunked a déjà été défini, ou - la requête est de type HTTP/1.1 et peut donc être définie à chunked.
+
le corps de la réponse a une taille définie suite au code de + statut 304 ou 204, la méthode de requête est HEAD, un en-tête + Content-Length ou Transfer-Encoding: chunked a déjà été défini, ou + la requête est de type HTTP/1.1 et peut donc être définie à chunked.
alors
-
keepalive est supporté.
+
keepalive est supporté.
- Le serveur peut décider de désactiver les - connexions persistantes pour de nombreuses raisons, comme un arrêt + Le serveur peut décider de désactiver les + connexions persistantes pour de nombreuses raisons, comme un arrêt imminent, un Connection: close en provenance du client, ou une - requête client de type HTTP/1.0 dont la réponse ne comporte pas - d'en-tête Content-Length, mais pour ce qui nous - concerne, nous ne vérifions que la possibilité des connexions + requête client de type HTTP/1.0 dont la réponse ne comporte pas + d'en-tête Content-Length, mais pour ce qui nous + concerne, nous ne vérifions que la possibilité des connexions persistantes depuis l'application, et non si les connexions - persistantes sont activées. + persistantes sont activées.

Notez aussi que le serveur HTTP Apache propose un filtre qui - ajoute un codage chunked aux réponses qui ne contiennent pas - d'en-tête Content-Length explicite. Cette politique - prend en compte les cas où le filtre est court-circuité ou - désactivé.

+ ajoute un codage chunked aux réponses qui ne contiennent pas + d'en-tête Content-Length explicite. Cette politique + prend en compte les cas où le filtre est court-circuité ou + désactivé.

-

Cette politique est implémentée par le filtre +

Cette politique est implémentée par le filtre POLICY_KEEPALIVE.

- Durée de fraîcheur / Politique de gestion de l'âge maximum + Durée de fraîcheur / Politique de gestion de l'âge maximum mod_policy @@ -396,39 +396,39 @@ -

Cette politique se verra rejetée si la réponse du serveur ne - contient pas de durée de fraîcheur explicite au - moins grande que la limite définie par le serveur, ou si la - durée de fraîcheur est calculée à partir d'une heuristique.

+

Cette politique se verra rejetée si la réponse du serveur ne + contient pas de durée de fraîcheur explicite au + moins grande que la limite définie par le serveur, ou si la + durée de fraîcheur est calculée à partir d'une heuristique.

-

Vous trouverez tous les détails à propos du calcul d'une durée de - fraîcheur dans la Vous trouverez tous les détails à propos du calcul d'une durée de + fraîcheur dans la RFC2616 section 13.2 Expiration Model.

-

Pendant la durée de fraîcheur, un cache n'a pas besoin de - contacter le serveur original, et il peut renvoyer le contenu situé +

Pendant la durée de fraîcheur, un cache n'a pas besoin de + contacter le serveur original, et il peut renvoyer le contenu situé dans le cache tel quel au client.

-

Lorsque la date de péremption est atteinte, le cache doit - contacter le serveur original dans le but de vérifier si le contenu - situé dans le cache est encore à jour, et si ce n'est pas le cas, de +

Lorsque la date de péremption est atteinte, le cache doit + contacter le serveur original dans le but de vérifier si le contenu + situé dans le cache est encore à jour, et si ce n'est pas le cas, de le remplacer par le contenu correspondant sur le serveur original.

-

Lorsque la durée de fraîcheur est trop courte, il peut en - résulter un excès de charge pour le serveur. De plus, si une - interruption de service survient, et si cette dernière est longue, - ou plus longue que la durée de fraîcheur, tout le contenu du cache - s'en trouvera périmé, ce qui causera un trafic très important - lorsque le serveur ou le réseau sera rétabli.

+

Lorsque la durée de fraîcheur est trop courte, il peut en + résulter un excès de charge pour le serveur. De plus, si une + interruption de service survient, et si cette dernière est longue, + ou plus longue que la durée de fraîcheur, tout le contenu du cache + s'en trouvera périmé, ce qui causera un trafic très important + lorsque le serveur ou le réseau sera rétabli.

-

Cette politique est implémentée par le filtre +

Cette politique est implémentée par le filtre POLICY_MAXAGE.

- Politique de gestion des contenus qui ne peuvent pas être mis + <title>Politique de gestion des contenus qui ne peuvent pas être mis en cache @@ -439,20 +439,20 @@ -

Cette politique sera rejetée si la réponse du serveur - déclare elle-même qu'elle ne doit pas être mise en cache à l'aide - d'un en-tête Cache-Control ou Pragma.

+

Cette politique sera rejetée si la réponse du serveur + déclare elle-même qu'elle ne doit pas être mise en cache à l'aide + d'un en-tête Cache-Control ou Pragma.

-

Vous trouverez tous les détails à propos de la manière dont un - contenu peut être déclaré comme non cachable dans la Vous trouverez tous les détails à propos de la manière dont un + contenu peut être déclaré comme non cachable dans la RFC2616 - section 14.9.1 What is Cacheable, et au sein de la définition de - l'en-tête Pragma dans la , et au sein de la définition de + l'en-tête Pragma dans la RFC2616 section 14.32 Pragma.

-

Plus précisément, si une combinaison des en-têtes suivants existe - dans la réponse, cette dernière sera rejetée :

+

Plus précisément, si une combinaison des en-têtes suivants existe + dans la réponse, cette dernière sera rejetée :

  • Cache-Control: no-cache
    • @@ -461,12 +461,12 @@
  • Pragma: no-cache
-

D'une manière générale, lorsque cette politique est activée, et - si d'une manière inattendue un contenu non cachable peut induire un - niveau de charge du serveur inacceptable, tout contenu défini comme - non cachable par le serveur sera rejeté.

+

D'une manière générale, lorsque cette politique est activée, et + si d'une manière inattendue un contenu non cachable peut induire un + niveau de charge du serveur inacceptable, tout contenu défini comme + non cachable par le serveur sera rejeté.

-

Cette politique est implémentée par le filtre +

Cette politique est implémentée par le filtre POLICY_NOCACHE.

@@ -482,34 +482,34 @@ -

Cette politique sera rejetée si la réponse du serveur - ne contient aucune en-tête syntaxiquement correct ETag +

Cette politique sera rejetée si la réponse du serveur + ne contient aucune en-tête syntaxiquement correct ETag ou Last-Modified.

-

Vous trouverez une description complète de l'en-tête +

Vous trouverez une description complète de l'en-tête ETag dans la RFC2616 - section 14.19 Etag, et de l'en-tête Last-Modified + section 14.19 Etag, et de l'en-tête Last-Modified dans la RFC2616 section 14.29 Last-Modified.

-

La vérification est effectuée non seulement en ce qui concerne la - présence des en-têtes, mais aussi du point de vue de leur syntaxe.

+

La vérification est effectuée non seulement en ce qui concerne la + présence des en-têtes, mais aussi du point de vue de leur syntaxe.

-

Si une en-tête ETag n'est pas entourée de guillemets, - ou n'est pas déclarée "weak" en le préfixant avec un "W/", la politique - sera rejetée. De même, si l'interprétation d'une en-tête - Last-Modified ne fournit pas de date valide, la réponse - sera rejetée.

+

Si une en-tête ETag n'est pas entourée de guillemets, + ou n'est pas déclarée "weak" en le préfixant avec un "W/", la politique + sera rejetée. De même, si l'interprétation d'une en-tête + Last-Modified ne fournit pas de date valide, la réponse + sera rejetée.

-

Cette politique est implémentée par le filtre +

Cette politique est implémentée par le filtre POLICY_VALIDATION.

- Politique de gestion de l'en-tête Vary + Politique de gestion de l'en-tête Vary mod_policy @@ -519,24 +519,24 @@ -

Cette politique se verra rejetée si la réponse du serveur - contient une en-tête Vary, et si cette en-tête - contient à son tour une en-tête mise en liste noire par +

Cette politique se verra rejetée si la réponse du serveur + contient une en-tête Vary, et si cette en-tête + contient à son tour une en-tête mise en liste noire par l'administrateur.

-

L'en-tête Vary est décrite en détails dans la L'en-tête Vary est décrite en détails dans la RFC2616 section 14.44 Vary.

-

Certaines en-têtes définies par les clients, comme - User-Agent, peuvent contenir des milliers ou même des +

Certaines en-têtes définies par les clients, comme + User-Agent, peuvent contenir des milliers ou même des millions de combinaisons de valeurs au cours du temps, et si la - réponse est considérée comme pouvant être mise en cache, le cache - peut tenter d'enregistrer toutes ces réponses, ce qui peut l'amener - à saturation et à noyer les autres entrées qu'il contient. Avec ce - scénario, cette politique sera rejetée.

+ réponse est considérée comme pouvant être mise en cache, le cache + peut tenter d'enregistrer toutes ces réponses, ce qui peut l'amener + à saturation et à noyer les autres entrées qu'il contient. Avec ce + scénario, cette politique sera rejetée.

-

Cette politique est implémentée par le filtre +

Cette politique est implémentée par le filtre POLICY_VARY.

@@ -552,24 +552,24 @@ -

Cette politique sera rejetée si la réponse du serveur - a été générée avec un numéro de version inférieur à la version - de HTTP spécifiée.

+

Cette politique sera rejetée si la réponse du serveur + a été générée avec un numéro de version inférieur à la version + de HTTP spécifiée.

-

Cette politique s'utilise en général avec les applications qui - nécessitent un contrôle du type du client. Elle peut être utilisée en +

Cette politique s'utilise en général avec les applications qui + nécessitent un contrôle du type du client. Elle peut être utilisée en concomitance avec le filtre POLICY_KEEPALIVE afin de s'assurer que les clients HTTP/1.0 n'engendrent pas la fermeture des connexions persistantes.

-

Les versions minimales pouvant être spécifiées sont :

+

Les versions minimales pouvant être spécifiées sont :

  • HTTP/1.1
  • HTTP/1.0
  • HTTP/0.9
-

Cette politique est implémentée par le filtre +

Cette politique est implémentée par le filtre POLICY_VERSON.

-- 2.40.0