Règles de site Web et paramètres Global Web
Les règles de site Web sont des documents qui vous aident à gérer l'organisation d'un site Web. Leur création a lieu en réponse à un document Site Web et s'appliquent uniquement à ce document Site Web. Pour appliquer une règle à plusieurs documents Site Web, copiez-collez le document de règle d'un document Site Web à l'autre.
Les règles de site Web ont deux utilisations principales :
- Pour permettre à l'administrateur de créer un schéma de navigation cohérent et convivial pour un site Web qui ne dépende pas de l'organisation physique réelle du site.
- Pour permettre la relocalisation ou la réorganisation d'éléments du site sans supprimer les liens existants ou les signets du navigateur.
Avant que les règles de site Web s'appliquent à une URL entrante, celle-ci est normalisée selon un jeu prédéfini de règles et de procédures de filtrage et de validation. Ces procédures convertissent l'URL dans un format sécurisé avant qu'elle soit transmise à une application pour processus. Une fois l'URL normalisée, la tâche HTTP utilise les règles définies pour le site Web afin de déterminer si l'URL doit subir une quelconque modification.
Il existe quatre types de règles de site Web. Si vous créez plusieurs types de règles de site Web dans un document Site Web, les documents de règle sont pris en compte dans l'ordre suivant :
- Substitution
- Redirection
- Répertoire
- En-têtes de réponse HTTP
Règles de substitution
Une règle de substitution remplace un ou plusieurs éléments de l'URL entrante par de nouvelles chaînes. Vous devez utiliser des règles de substitution pour réorganiser votre site Web sans réécrire tous les liens du site ou pour fournir des alias conviviaux pour les URL complexes.
Une règle de substitution s'avère par exemple utile pour déplacer un groupe de fichiers de votre site Web d'un répertoire à un autre. Au lieu de réparer tous les liens qui font référence à l'ancien répertoire, la règle de substitution mappe l'ancien répertoire au nouveau.
Les modèles entrants et de remplacement des règles de substitution doivent contenir au moins un caractère générique. Si vous n'incluez pas explicitement un caractère générique dans un modèle, la tâche HTTP ajoute automatiquement /*
à la fin du modèle lorsqu'elle enregistre la règle dans sa table interne.
Règles de redirection
Les règles de redirection redirigent les URL entrantes vers d'autres URL. Il existe deux types de règles de redirection : externes ou internes. Si vous utilisez une règle de redirection externe, le serveur informe le navigateur qu'un fichier ou une autre ressource demandée par le navigateur est localisé dans une autre URL. Si le chemin de l'URL entrante correspond à une règle de redirection externe, la tâche HTTP génère une nouvelle URL basée sur le modèle de redirection et renvoie immédiatement cette URL au navigateur. Grâce aux règles de redirection externes, les liens et signets existants demeurent valides et les nouveaux signets pointent vers le nouvel emplacement.
Une règle de redirection interne agit comme une règle de substitution en ce sens que la tâche HTTP génère une nouvelle URL, puis la normalise de nouveau. Il existe cependant deux différences entre ces règles. Tout d'abord, les recherches dans la table de redirection sont effectuées de façon récursive, de sorte que vous pouvez créer et imbriquer plusieurs règles de redirection. Deuxièmement, les règles de redirection internes ne requièrent pas l'utilisation de caractères génériques. Ainsi, pour imposer une correspondance exacte avec le chemin de l'URL, utilisez une règle de redirection interne plutôt qu'une règle de substitution.
Si le chemin de l'URL entrante correspond à une règle de redirection interne, la tâche HTTP génère un nouveau chemin, le normalise et relance une recherche dans la table de redirection. Comme la tâche HTTP effectue une recherche récursive dans la table de la règle de redirection, vous pouvez rédiger de longues règles de redirection qui collectent les URL, quelle que soit la substitution ou la redirection appliquée.
Les caractères génériques sont autorisés mais non requis dans les règles de redirection.
Règles d'annuaire
Une règle d'annuaire mappe le répertoire d'un système de fichiers à un modèle d'URL. Lorsque le serveur Web reçoit une URL qui correspond au modèle, il suppose que l'URL demande une ressource de ce répertoire.
Lorsque vous installez un serveur Web Domino®, plusieurs répertoires de ressources de fichiers sont créés automatiquement. Ces répertoires par défaut sont mappés par des règles d'annuaire définies dans l'onglet Configuration du document Site Web. Lorsque le serveur Web démarre, il crée automatiquement des règles internes pour mapper ces répertoires aux modèles d'URL. Les trois répertoires par défaut sont les suivants :
- Répertoire HTML pour les fichiers non graphiques
- Répertoire d'icônes pour les images graphiques (.GIF, par exemple)
- Répertoire CGI pour les programmes CGI
Les règles d'annuaire peuvent être utilisées uniquement pour mapper l'emplacement de fichiers lus directement (fichiers HTML et fichiers graphiques, par exemple) et de programmes exécutables chargés et exécutés par le système d'exploitation (programmes CGI, par exemple). Les règles d'annuaire ne peuvent pas être utilisées pour mapper l'emplacement d'autres types de ressources, telles que les bases Domino® ou les servlets Java™.
Lorsque vous créez une règle Site Web d'annuaire, vous devez spécifier des droits d'accès en lecture ou en exécution au répertoire du système de fichiers. Le choix du droit d'accès est essentiel. Seuls les répertoires contenant des programmes CGI doivent être activés pour un accès en exécution. Tous les autres répertoires doivent disposer d'un accès en lecture. Si vous spécifiez un niveau d'accès incorrect, des erreurs inattendues surviennent. Par exemple, si vous attribuez un accès en lecture à un répertoire CGI et qu'un utilisateur du navigateur envoie une URL pour un programme CGI, le serveur renvoie le code source du programme au lieu de l'exécuter, ce qui peut créer une grave menace de sécurité.
Les règles d'annuaire ne peuvent pas écraser les droits d'accès aux fichiers appliqués par le système d'exploitation.
Règles d'en-tête de réponse HTTP
Chaque réponse de serveur et demande de navigateur HTTP commence par un jeu d'en-têtes qui décrit les données transmises. Une règle d'en-tête de réponse HTTP permet au concepteur d'une application de personnaliser les en-têtes envoyés par Domino® (en-tête d'expiration ou en-têtes personnalisés pour les réponses HTTP, par exemple) avec les réponses aux demandes qui correspondent au modèle d'URL spécifié.
L'objectif principal des règles de réponse est l'amélioration des performances des fonctions de cache du navigateur. Un concepteur d'applications peut ajouter des en-têtes qui fournissent au navigateur des informations importantes sur la volatilité des éléments mis en mémoire cache.
Les en-têtes de cache incluent l'en-tête de date de dernière modification, l'en-tête de date d'expiration et l'en-tête de contrôle du cache. L'en-tête de date de dernière modification indique quand les ressources utilisées pour générer une réponse ont été modifiées pour la dernière fois. L'en-tête de date d'expiration indique au navigateur la date à laquelle les ressources vont être modifiées. Un concepteur peut définir une règle pour ajouter des en-têtes de date d'expiration aux réponses sur la base de la date à laquelle le concepteur prévoit une modification des ressources. L'en-tête de contrôle du cache fournit des instructions aux caches du serveur proxy et du navigateur, telles que "no-cache" (pas de cache) pour les réponses qui ne doivent pas être mises en mémoire cache ou "private" (privé) pour les réponses qui peuvent être mises en mémoire cache mais qui sont propres à une configuration de navigateur spécifique.
Vous pouvez également utiliser des règles de réponse pour personnaliser les en-têtes. Par exemple, vous pouvez créer des règles de réponse pour des en-têtes personnalisés qui affichent des messages d'erreur spécifiques (par exemple, lorsqu'un utilisateur n'est pas autorisé à accéder à une application).
Contrairement aux autres règles de site Web, les règles de réponse sont appliquées à la réponse sortante, juste avant que la tâche HTTP ne la transmette au navigateur. Pour les règles d'en-tête de réponse, le modèle est comparé au format final d'une URL, après application des règles de substitution et de redirection. Par exemple, si vous avez créé une règle de substitution qui transforme /help/*
et /support.nsf/helpview/*
et que vous souhaitez créer une règle de réponse qui corresponde à la réponse, le modèle de la règle de réponse doit être : /support.nsf/helpview/*
.
Le modèle peut inclure un ou plusieurs astérisques comme caractères génériques. Par exemple, le modèle /*/catalog/*.htm
correspond aux URL /petstore/catalog/food.htm
, /clothing/catalog/thumbnails.htm
, etc. Les règles de réponse ne requièrent pas de caractères génériques. Cela vous permet de créer une règle qui correspond à une ressource spécifique, par exemple, /cgi-bin/account.pl. A l'instar de toutes les règles, le modèle entrant ne peut pas contenir de chaîne de requête.
Les règles d'en-tête de réponse diffèrent des autres règles en ce sens qu'elles ne doivent pas seulement correspondre à un modèle d'URL mais également au code d'état de la réponse HTTP. Vous devez spécifier un ou plusieurs codes d'état dans le champ des codes de réponse HTTP.
Paramètres Global Web
Les paramètres Global Web vous permettent d'appliquer des règles Web à plusieurs sites Web. Attribuez un nom au document Paramètres Global Web et indiquez les serveurs auxquels ces paramètres s'appliquent. Créez ensuite des documents de règles Web pour un document Paramètres Global Web. Les règles Web s'appliquent ensuite à tous les sites Web hébergés par les serveurs indiqués dans le document des paramètres Global Web.
Le document des paramètres Global Web et les documents de règles de site Web ne sont pas automatiquement créés. Pour utiliser le document des paramètres Global Web et des règles de site Web dans votre environnement Web, vous devez les créer manuellement.