Conformité au protocole HTTP

Langues Disponibles: en | + fr

+ +

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 à + quoi est du ce rejet et ce qu'ils doivent faire pour corriger + l'erreur.

Imposer la conformité au protocole HTTP dans Apache 2
Politique des requêtes conditionnelles
Politique de gestion de l'en-tête Content-Length
Politique de filtrage de l'en-tête Content-Type
Politique de gestion des connexions persistantes (Keepalive)
Durée de fraîcheur / Politique de gestion de l'âge maximum
Politique de gestion des contenus qui ne peuvent pas être mis + en cache
Politique de validation
Politique de gestion de l'en-tête Vary
Politique de gestion des versions de protocole

Voir aussi

Filtres

Commentaires

Imposer la conformité au protocole HTTP dans Apache 2

Modules Apparentés	Directives Apparentées
`mod_policy`	`PolicyConditional` `PolicyLength` `PolicyKeepalive` `PolicyType` `PolicyVary` `PolicyValidation` `PolicyNocache` `PolicyMaxage` `PolicyVersion`

+ + + +

Le protocole HTTP applique le principe de + robustesse décrit dans la RFC1122, et stipulant + "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 + 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 + 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. +

+ +

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.

+ +

+ Imposer la conformité au protocole HTTP pour un serveur d'applications +

+ +

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 + 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.

+ +

+ 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 + s'assurer que sa configuration respecte un niveau minimum de + conformité au protocole HTTP.

+ +

Politique des requêtes conditionnelles

Modules Apparentés	Directives Apparentées
`mod_policy`	`PolicyConditional`

+ + + +

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.

+ +

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 + code d'erreur 412 Precondition Failed. Vous trouverez + 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 + 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 + 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 + renvoyer 412 Precondition Failed. Vous trouverez + 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 + renvoyer 206 Partial Response. Vous trouverez + 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.

+ +

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

+ +

Politique de gestion de l'en-tête Content-Length

Modules Apparentés	Directives Apparentées
`mod_policy`	`PolicyLength`

+ + + +

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 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 + 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.

+ +

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 + (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 + 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 + POLICY_LENGTH.

+ +

Politique de filtrage de l'en-tête Content-Type

Modules Apparentés	Directives Apparentées
`mod_policy`	`PolicyType`

+ + + +

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.

+ +

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 + sera du style :

+ +

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

+ +

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

+ +

+ # invalide + Content-Type: foo + # vide + Content-Type: +

+ +

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 + POLICY_TYPE.

+ +

Politique de gestion des connexions persistantes (Keepalive)

Modules Apparentés	Directives Apparentées
`mod_policy`	`PolicyKeepalive`

+ + + +

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 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 à + 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 + (keepalive). +

+ +

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

+ +

Si: 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 ;
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.
alors: keepalive est supporté.

+ +

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 + persistantes depuis l'application, et non si les connexions + 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é.

+ +

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

+ +

Durée de fraîcheur / Politique de gestion de l'âge maximum

Modules Apparentés	Directives Apparentées
`mod_policy`	`PolicyMaxage`

+ + + +

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 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é + 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 + 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.

+ +

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

+ +

Politique de gestion des contenus qui ne peuvent pas être mis + en cache

Modules Apparentés	Directives Apparentées
`mod_policy`	`PolicyNocache`

+ + + +

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 RFC2616 + section 14.9.1 What is Cacheable, 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 :

+ +

Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: private
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é.

+ +

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

+ +

Politique de validation

Modules Apparentés	Directives Apparentées
`mod_policy`	`PolicyValidation`

+ + + +

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 + ETag dans la RFC2616 + 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.

+ +

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 + POLICY_VALIDATION.

+ +

Politique de gestion de l'en-tête Vary

Modules Apparentés	Directives Apparentées
`mod_policy`	`PolicyVary`

+ + + +

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 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 + 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.

+ +

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

+ +

Politique de gestion des versions de protocole

Modules Apparentés	Directives Apparentées
`mod_policy`	`PolicyVersion`

+ + + +

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 + 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 :

+ +

HTTP/1.1
HTTP/1.0
HTTP/0.9

+ +

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

+ +

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.