| <?xml version="1.0" encoding="ISO-8859-1" ?> |
| <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd"> |
| <?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?> |
| <!-- English Revision: 1673947 --> |
| <!-- French translation : Lucien GENTIS --> |
| <!-- Reviewed by : Vincent Deffontaines --> |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <manualpage metafile="compliance.xml.meta"> |
| |
| <title>Conformité au protocole HTTP</title> |
| |
| <summary> |
| <p>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.</p> |
| |
| <p>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.</p> |
| </summary> |
| <seealso><a href="filter.html">Filtres</a></seealso> |
| |
| <section id="intro"> |
| <title>Imposer la conformité au protocole HTTP dans Apache 2</title> |
| <related> |
| <modulelist> |
| <module>mod_policy</module> |
| </modulelist> |
| <directivelist> |
| <directive module="mod_policy">PolicyConditional</directive> |
| <directive module="mod_policy">PolicyLength</directive> |
| <directive module="mod_policy">PolicyKeepalive</directive> |
| <directive module="mod_policy">PolicyType</directive> |
| <directive module="mod_policy">PolicyVary</directive> |
| <directive module="mod_policy">PolicyValidation</directive> |
| <directive module="mod_policy">PolicyNocache</directive> |
| <directive module="mod_policy">PolicyMaxage</directive> |
| <directive module="mod_policy">PolicyVersion</directive> |
| </directivelist> |
| </related> |
| |
| <p>Le protocole HTTP applique le <strong>principe de |
| robustesse</strong> décrit dans la <a |
| href="http://tools.ietf.org/html/rfc1122">RFC1122</a>, et stipulant |
| <strong>"Soyez libéral pour ce que vous acceptez, conservateur pour |
| ce que vous envoyez"</strong>. 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.</p> |
| |
| <p>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é.</p> |
| |
| <p>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.</p> |
| |
| <p>Le module <module>mod_policy</module> 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 |
| 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 |
| de l'environnement. |
| </p> |
| |
| <p>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.</p> |
| |
| <p class="figure"> |
| <img src="images/compliance-reverse-proxy.png" width="666" height="239" alt= |
| "Imposer la conformité au protocole HTTP pour un serveur |
| d'applications"/> |
| </p> |
| |
| <p>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 <module>mod_policy</module> ont été |
| ajoutés pour imposer le support de la mise en cache de contenu et |
| des requêtes conditionnelles, assurant ainsi que |
| <module>mod_cache</module> et les caches publics de l'internet |
| seront pleinement capables de mettre en cache le contenu créé avec |
| efficacité par le serveur d'applications.</p> |
| |
| <p class="figure"> |
| <img src="images/compliance-static.png" width="469" height="239" alt= |
| "Imposer la conformité au protocole HTTP pour un serveur statique"/> |
| </p> |
| |
| <p>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 |
| s'assurer que sa configuration respecte un niveau minimum de |
| conformité au protocole HTTP.</p> |
| |
| </section> |
| |
| <section id="policyconditional"> |
| <title>Politique des requêtes conditionnelles</title> |
| <related> |
| <modulelist> |
| <module>mod_policy</module> |
| </modulelist> |
| <directivelist> |
| <directive module="mod_policy">PolicyConditional</directive> |
| </directivelist> |
| </related> |
| |
| <p>Cette politique sera rejetée si le serveur ne répond pas à une |
| requête conditionnelle avec le code d'état approprié. </p> |
| |
| <p>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.</p> |
| |
| <p>Plus particulièrement, la présence d'une des en-têtes suivantes |
| dans la requête rend cette dernière conditionnelle :</p> |
| |
| <dl> |
| <dt><code>If-Match</code></dt> |
| <dd>Si l'ETag fourni dans l'en-tête <code>If-Match</code> ne |
| correspond pas à l'ETag de la réponse, le serveur doit renvoyer un |
| code d'erreur <code>412 Precondition Failed</code>. Vous trouverez |
| tous les détails du traitement d'un en-tête <code>If-Match</code> |
| dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24">RFC2616 |
| section 14.24</a>.</dd> |
| |
| <dt><code>If-None-Match</code></dt> |
| <dd>Si l'ETag fourni dans l'en-tête <code>If-None-Match</code> |
| correspond à l'ETag de la réponse, le serveur doit renvoyer soit |
| <code>304 Not Modified</code> pour les requêtes GET/HEAD, soit |
| <code>412 Precondition Failed</code> pour les autres méthodes. Vous trouverez |
| tous les détails du traitement d'un en-tête |
| <code>If-None-Match</code> dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26">RFC2616 |
| section 14.26</a>.</dd> |
| |
| <dt><code>If-Modified-Since</code></dt> |
| <dd>Si la date fournie dans l'en-tête <code>If-Modified-Since</code> |
| est plus ancienne que celle de l'en-tête <code>Last-Modified</code> |
| de la réponse, le serveur doit renvoyer <code>304 Not Modified</code>. Vous trouverez |
| tous les détails du traitement d'un en-tête |
| <code>If-Modified-Since</code> dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25">RFC2616 |
| section 14.25</a>.</dd> |
| |
| <dt><code>If-Unmodified-Since</code></dt> |
| <dd>Si la date fournie dans l'en-tête |
| <code>If-Unmodified-Since</code> est plus récente que celle de |
| l'en-tête <code>Last-Modified</code> de la réponse, le serveur doit |
| renvoyer <code>412 Precondition Failed</code>. Vous trouverez |
| tous les détails du traitement d'un en-tête |
| <code>If-Unmodified-Since</code> dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.28">RFC2616 |
| section 14.28</a>.</dd> |
| |
| <dt><code>If-Range</code></dt> |
| <dd>Si l'ETag fourni dans l'en-tête <code>If-Range</code> correspond |
| à l'ETag ou à l'en-tête Last-Modified de la réponse, et si un |
| en-tête <code>Range</code> valide est présent, le serveur doit |
| renvoyer <code>206 Partial Response</code>. Vous trouverez |
| tous les détails du traitement d'un en-tête <code>If-Range</code> |
| dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.27">RFC2616 |
| section 14.27</a>.</dd> |
| |
| </dl> |
| |
| <p>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.</p> |
| |
| <p>Cette politique est implémentée par le filtre |
| <strong>POLICY_CONDITIONAL</strong>.</p> |
| |
| </section> |
| |
| <section id="policylength"> |
| <title>Politique de gestion de l'en-tête Content-Length</title> |
| <related> |
| <modulelist> |
| <module>mod_policy</module> |
| </modulelist> |
| <directivelist> |
| <directive module="mod_policy">PolicyLength</directive> |
| </directivelist> |
| </related> |
| |
| <p>Cette politique sera rejetée si la réponse du serveur ne contient pas d'en-tête |
| <code>Content-Length</code> explicite.</p> |
| |
| <p>De nombreuses méthodes pour déterminer la taille d'un |
| corps de réponse sont décrites dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4">RFC2616 |
| section 4.4 Message Length</a>.</p> |
| |
| <p>Lorsque l'en-tête <code>Content-Length</code> 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.</p> |
| |
| <p>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 <code>Transfer-Encoding</code> comme une alternative à |
| <code>Content-Length</code>. Cependant, lors du traitement de |
| requêtes HTTP/1.0, et si l'en-tête <code>Content-Length</code> 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). |
| </p> |
| |
| <p>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 <code>204 No |
| Content</code>), et si l'en-tête <code>Content-Length</code> 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.</p> |
| |
| <note type="warning">Notez que certains modules comme |
| <module>mod_proxy</module> ajoutent leur propre en-tête |
| <code>Content-Length</code> 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.</note> |
| |
| <p>Cette politique est implémentée par le filtre |
| <strong>POLICY_LENGTH</strong>.</p> |
| |
| </section> |
| |
| <section id="policytype"> |
| <title>Politique de filtrage de l'en-tête Content-Type</title> |
| <related> |
| <modulelist> |
| <module>mod_policy</module> |
| </modulelist> |
| <directivelist> |
| <directive module="mod_policy">PolicyType</directive> |
| </directivelist> |
| </related> |
| |
| <p>Cette politique sera rejetée si la réponse du serveur ne contient pas d'en-tête |
| <code>Content-Type</code> explicite et valide du point de vue de la |
| syntaxe, correspondant au modèle défini par le serveur.</p> |
| |
| <p>Le type de media du corps est placé dans une en-tête |
| <code>Content-Type</code> dont le format est décrit en détail dans |
| la <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7"> |
| RFC2616 section 3.7 Media Types</a>.</p> |
| |
| <p>Une en-tête <code>Content-Type</code> dont la syntaxe est valide |
| sera du style :</p> |
| |
| <example> |
| Content-Type: text/html; charset=iso-8859-1 |
| </example> |
| |
| <p>Exemples d'en-têtes <code>Content-Type</code> non valides :</p> |
| |
| <example> |
| # invalide<br /> |
| Content-Type: foo<br /> |
| # vide<br /> |
| Content-Type: |
| </example> |
| |
| <p>L'administrateur peut restreindre la politique à un ou plusieurs |
| types spécifiques, ou utiliser des caractères génériques comme |
| <code>*/*</code>.</p> |
| |
| <p>Cette politique est mise en oeuvre par le filtre |
| <strong>POLICY_TYPE</strong>.</p> |
| |
| </section> |
| |
| <section id="policykeepalive"> |
| <title>Politique de gestion des connexions persistantes (Keepalive)</title> |
| <related> |
| <modulelist> |
| <module>mod_policy</module> |
| </modulelist> |
| <directivelist> |
| <directive module="mod_policy">PolicyKeepalive</directive> |
| </directivelist> |
| </related> |
| |
| <p>Cette politique era rejetée si la réponse du serveur ne contient pas d'en-tête |
| <code>Content-Length</code> explicite, ou d'en-tête |
| <code>Transfer-Encoding</code> défini à chunked.</p> |
| |
| <p>De nombreuses manières pour déterminer la taille d'un |
| corps de réponse sont décrites dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4">RFC2616 |
| section 4.4 Message Length</a>.</p> |
| |
| <p>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 <code>Transfer-Encoding</code> comme une alternative à |
| <code>Content-Length</code>. Cependant, lors du traitement de |
| requêtes HTTP/1.0, et si l'en-tête <code>Content-Length</code> 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). |
| </p> |
| |
| <p>En particulier, les règles suivantes sont appliquées : </p> |
| |
| <dl> |
| <dt>Si</dt> |
| <dd>cette connexion n'est pas marquée en erreur ;</dd> |
| |
| <dt>et</dt> |
| <dd>le client n'attend pas 100-continue ;</dd> |
| |
| <dt>et</dt> |
| <dd>le code de statut de la réponse ne nécessite pas de fermeture de connexion ;</dd> |
| |
| <dt>et</dt> |
| <dd>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.</dd> |
| |
| <dt>alors</dt> |
| <dd>keepalive est supporté.</dd> |
| </dl> |
| |
| <note type="warning">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 <code>Content-Length</code>, 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.</note> |
| |
| <p>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 <code>Content-Length</code> explicite. Cette politique |
| prend en compte les cas où le filtre est court-circuité ou |
| désactivé.</p> |
| |
| <p>Cette politique est implémentée par le filtre |
| <strong>POLICY_KEEPALIVE</strong>.</p> |
| |
| </section> |
| |
| <section id="policymaxage"> |
| <title>Durée de fraîcheur / Politique de gestion de l'âge maximum</title> |
| <related> |
| <modulelist> |
| <module>mod_policy</module> |
| </modulelist> |
| <directivelist> |
| <directive module="mod_policy">PolicyMaxage</directive> |
| </directivelist> |
| </related> |
| |
| <p>Cette politique se verra rejetée si la réponse du serveur ne |
| contient pas de <strong>durée de fraîcheur</strong> 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.</p> |
| |
| <p>Vous trouverez tous les détails à propos du calcul d'une durée de |
| fraîcheur dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2">RFC2616 |
| section 13.2 Expiration Model</a>.</p> |
| |
| <p>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.</p> |
| |
| <p>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.</p> |
| |
| <p>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.</p> |
| |
| <p>Cette politique est implémentée par le filtre |
| <strong>POLICY_MAXAGE</strong>.</p> |
| |
| </section> |
| |
| <section id="policynocache"> |
| <title>Politique de gestion des contenus qui ne peuvent pas être mis |
| en cache</title> |
| <related> |
| <modulelist> |
| <module>mod_policy</module> |
| </modulelist> |
| <directivelist> |
| <directive module="mod_policy">PolicyNocache</directive> |
| </directivelist> |
| </related> |
| |
| <p>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 <code>Cache-Control</code> ou <code>Pragma</code>.</p> |
| |
| <p>Vous trouverez tous les détails à propos de la manière dont un |
| contenu peut être déclaré comme non cachable dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1">RFC2616 |
| section 14.9.1 What is Cacheable</a>, et au sein de la définition de |
| l'en-tête <code>Pragma</code> dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32">RFC2616 |
| section 14.32 Pragma</a>.</p> |
| |
| <p>Plus précisément, si une combinaison des en-têtes suivants existe |
| dans la réponse, cette dernière sera rejetée :</p> |
| |
| <ul> |
| <li><code>Cache-Control: no-cache</code></li> |
| <li><code>Cache-Control: no-store</code></li> |
| <li><code>Cache-Control: private</code></li> |
| <li><code>Pragma: no-cache</code></li> |
| </ul> |
| |
| <p>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é.</p> |
| |
| <p>Cette politique est implémentée par le filtre |
| <strong>POLICY_NOCACHE</strong>.</p> |
| |
| </section> |
| |
| <section id="policyvalidation"> |
| <title>Politique de validation</title> |
| <related> |
| <modulelist> |
| <module>mod_policy</module> |
| </modulelist> |
| <directivelist> |
| <directive module="mod_policy">PolicyValidation</directive> |
| </directivelist> |
| </related> |
| |
| <p>Cette politique sera rejetée si la réponse du serveur |
| ne contient aucune en-tête syntaxiquement correct <code>ETag</code> |
| ou <code>Last-Modified</code>.</p> |
| |
| <p>Vous trouverez une description complète de l'en-tête |
| <code>ETag</code> dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19">RFC2616 |
| section 14.19 Etag</a>, et de l'en-tête <code>Last-Modified</code> |
| dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.29">RFC2616 |
| section 14.29 Last-Modified</a>.</p> |
| |
| <p>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.</p> |
| |
| <p>Si une en-tête <code>ETag</code> 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 |
| <code>Last-Modified</code> ne fournit pas de date valide, la réponse |
| sera rejetée.</p> |
| |
| <p>Cette politique est implémentée par le filtre |
| <strong>POLICY_VALIDATION</strong>.</p> |
| |
| </section> |
| |
| <section id="policyvary"> |
| <title>Politique de gestion de l'en-tête Vary</title> |
| <related> |
| <modulelist> |
| <module>mod_policy</module> |
| </modulelist> |
| <directivelist> |
| <directive module="mod_policy">PolicyVary</directive> |
| </directivelist> |
| </related> |
| |
| <p>Cette politique se verra rejetée si la réponse du serveur |
| contient une en-tête <code>Vary</code>, et si cette en-tête |
| contient à son tour une en-tête mise en liste noire par |
| l'administrateur.</p> |
| |
| <p>L'en-tête <code>Vary</code> est décrite en détails dans la <a |
| href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44">RFC2616 |
| section 14.44 Vary</a>.</p> |
| |
| <p>Certaines en-têtes définies par les clients, comme |
| <code>User-Agent</code>, 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.</p> |
| |
| <p>Cette politique est implémentée par le filtre |
| <strong>POLICY_VARY</strong>.</p> |
| |
| </section> |
| |
| <section id="policyversion"> |
| <title>Politique de gestion des versions de protocole</title> |
| <related> |
| <modulelist> |
| <module>mod_policy</module> |
| </modulelist> |
| <directivelist> |
| <directive module="mod_policy">PolicyVersion</directive> |
| </directivelist> |
| </related> |
| |
| <p>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.</p> |
| |
| <p>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 <code>POLICY_KEEPALIVE</code> afin de |
| s'assurer que les clients HTTP/1.0 n'engendrent pas la fermeture des |
| connexions persistantes.</p> |
| |
| <p>Les versions minimales pouvant être spécifiées sont :</p> |
| |
| <ul><li><code>HTTP/1.1</code></li> |
| <li><code>HTTP/1.0</code></li> |
| <li><code>HTTP/0.9</code></li> |
| </ul> |
| |
| <p>Cette politique est implémentée par le filtre |
| <strong>POLICY_VERSON</strong>.</p> |
| |
| </section> |
| </manualpage> |
