Conformité au protocole HTTP

Imposer la conformité au protocole HTTP dans Apache 2 ¶

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.

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.

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 ¶

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 ¶

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.

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

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

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 :

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

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) ¶

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

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 ¶

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 ¶

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 ¶

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 ¶

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 ¶

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.