Cette présente les directives contenues dans le fichier de configuration ibmproxy.conf.
Utilisez ces informations comme référence si vous configurez le serveur en éditant le fichier de configuration ibmproxy.conf. Si vous utilisez les formulaires de configuration et d'administration, il n'est pas nécessaire de consulter ce chapitre.
Les directives sont classées dans une liste par ordre alphabétique.
Certaines directives ne sont pas régénérées lors du redémarrage du serveur. Si les directives suivantes sont modifiées lors de l'exécution du serveur, vous devrez arrêter manuellement ce dernier puis le redémarrer. (Voir Démarrage et arrêt de Caching Proxy.)
Groupe de directives | Directives |
CGI | DisinheritEnv, InheritEnv |
Mise en mémoire cache | Mise en mémoire cache |
Journalisation | AccessLog, CacheAccessLog, ErrorLog, ProxyAccessLog, ServerRoot |
Accès réseau | BindSpecific, Hostname, ListenBacklog, Port |
Performance | MaxActiveThreads |
RTSP | Toutes les directives RTSP |
SSL | Toutes les directives SSL |
Contrôle de processus Linux et UNIX | GroupId, UserId |
Divers | TransparentProxy |
Cette annexe fournit les informations suivantes sur chaque directive :
NomDirective valeur
Il s'agit des valeurs d'origine codées dans le fichier de configuration par défaut. Modifiez uniquement les parties du fichier de configuration devant être différentes des paramètres par défaut. Une directive pour laquelle aucune valeur par défaut n'est codée à l'origine apparaît dans le fichier précédée d'un symbole de commentaire (#). Pour spécifier une valeur pour cette directive, supprimez le symbole de commentaire et ajoutez la valeur sur la ligne dans le fichier de configuration.
La liste suivante répertorie les valeurs acceptées dans le fichier de configuration :
Toutes les entrées sont converties en secondes et ajoutées les unes aux autres.
Lorsque vous éditez le fichier de configuration, n'oubliez pas que :
Vous trouverez ci-après les directives du module Caching Proxy.
Cette directive permet de servir tous les fichiers vers le client même si le type MIME du fichier ne correspond à aucun en-tête ACCEPT: envoyé par le client. Si cette directive a la valeur OFF, les fichiers dont le type MIME diffère de ceux acceptés par le client ne seront pas affichés. A la place, une page d'erreur est affichée.
AcceptAnything {on | off}
AcceptAnything off
AcceptAnything on
Cette directive permet de spécifier le répertoire et le nom du fichier dans lequel le serveur doit consigner les statistiques d'accès au serveur. Par défaut, le serveur écrit une entrée dans ce fichier journal dès qu'un client envoie au serveur une demande relative aux données stockées sur le serveur local. Généralement, ces données incluent uniquement les demandes provenant du client de configuration ou les accès lorsque la machine Caching Proxy est utilisée en tant que serveur d'origine. Ce fichier journal ne contient pas d'informations sur l'accès à la mémoire cache ou au serveur proxy.
Utilisez la directive NoLog pour spécifier les clients dont vous ne souhaitez pas consigner les accès. Pour obtenir une description de la directive NoLog, voir NoLog — Supprime les entrées de journal pour des hôtes spécifiques ou des domaines correspondant à un modèle.
Le serveur démarre un nouveau fichier journal chaque jour à minuit s'il est en cours d'exécution. Sinon, le serveur démarre un nouveau fichier journal dès que vous le démarrez. Lors de la création du fichier, le serveur utilise le nom du fichier spécifié et ajoute un suffixe de date. Le suffixe de date apparaît au format Mmmjjaaaa, où Mmm correspond aux trois premières lettres du mois, jj correspond au jour du mois et aaaa à l'année.
Nous vous recommandons de supprimer les anciens fichiers journaux car ils peuvent occuper un espace disque important sur votre disque dur.
AccessLog
/chemin_répertoire/nom_journal
AccessLog /logs/accesslog
Utilisez cette directive pour empêcher la consignation des demandes effectuées selon une méthode particulière pour accéder aux fichiers et répertoires. Par exemple, vous pouvez choisir de ne pas consigner les demandes de suppression pour les fichiers ou les répertoires.
Vous pouvez avoir plusieurs occurrences de cette directive dans votre fichier de configuration. Vous pouvez placer plusieurs méthodes au niveau de la même directive si vous les séparez par un ou plusieurs caractères d'espacement.
AccessLogExcludeMethod méthode [...]
AccessLogExcludeMethod GET
AccessLogExcludeMethod PUT
AccessLogExcludeMethod POST
AccessLogExcludeMethod DELETE
AccessLogExcludeMethod GET PUT
Aucune. Le serveur inclut dans le fichier journal des accès les fichiers et les répertoires requis par tous les types de méthode.
Cette directive permet de spécifier que vous ne voulez pas consigner dans le fichier journal de Proxy les demandes d'accès aux répertoires ou aux fichiers d'un type MIME donné. (text/html, image/gif et image/jpeg constituent des exemples de types MIME.) Par exemple, vous pouvez choisir de ne pas consigner les demandes d'accès pour les images GIF.
Vous pouvez avoir plusieurs occurrences de cette directive dans votre fichier de configuration. Vous pouvez également placer plusieurs types MIME au niveau de la même directive si vous les séparez par un ou plusieurs espaces.
AccessLogExcludeMimeType type_MIME
[...]
AccessLogExcludeMimeType image/gif
AccessLogExcludeMimeType text/html
AccessLogExcludeMimeType image/gif text/html
Aucune. Le fichier journal des accès inclut les demandes vers le serveur pour les fichiers et les répertoires de tous les types MIME.
Cette directive permet de spécifier que vous ne voulez pas consigner les demandes d'accès comprises dans une fourchette de numéros de codes d'erreur. Ces codes d'erreur sont des codes de statut de serveur proxy. Vous ne pouvez pas spécifier de codes individuels. Lorsque vous indiquez 300, vous voulez exclure les demandes d'accès comportant des codes de réacheminement (301, 302, 303 et 304).
Vous pouvez avoir plusieurs occurrences de cette directive dans votre fichier de configuration. Vous pouvez également placer plusieurs codes retour au niveau de la même directive si vous les séparez par un ou plusieurs espaces.
AccessLogExcludeReturnCode fourchette
AccessLogExcludeReturnCode 300
Aucune. Le fichier journal des accès inclut toutes les demandes adressées au serveur, quel que soit le code.
Cette directive permet de spécifier que vous ne voulez pas consigner les demandes d'accès à des fichiers ou des répertoires spécifiques qui correspondent à un modèle d'URL donné. Par exemple, vous pouvez ne pas consigner les demandes d'accès à des fichiers GIF ou ne pas consigner les demandes d'accès à un fichier ou un répertoire particulier du serveur.
Vous pouvez avoir plusieurs occurrences de cette directive dans votre fichier de configuration. Vous pouvez également placer plusieurs entrées pour la même directive si vous les séparez par un ou plusieurs espaces.
AccessLogExcludeURL fichier_ou_type
[...]
AccessLogExcludeURL *.gif
AccessLogExcludeURL /Freebies/*
AccessLogExcludeURL *.gif /Freebies/*
Aucune. Le serveur consigne les demandes d'accès à tous les fichiers et répertoires.
Cette directive permet d'indiquer que vous ne voulez par consigner les demandes d'accès effectuées par des agents utilisateur spécifiques (par exemple, Internet Explorer 5.0).
Vous pouvez avoir plusieurs occurrences de cette directive dans votre fichier de configuration. Vous pouvez également placer plusieurs entrées pour la même directive si vous les séparez par un ou plusieurs espaces.
AccessLogExcludeUserAgent
agent_utilisateur
[...]
AccessLogExcludeUserAgent *Mozilla/2.0
AccessLogExcludeUserAgent *MSIE 5*
Par défaut, le fichier ibmproxy.conf contient les définitions suivantes pour la directive AccessLogExcludeUserAgent :
AccessLogExcludeUserAgent IBM_Network_Dispatcher_HTTP_Advisor
AccessLogExcludeUserAgent IBM_Network_Dispatcher_WTE_Advisor
Les agents utilisateur répertoriés ci-dessus sont ceux qui ont été définis pour certains assistants du composant Load Balancer se trouvant généralement devant le serveur Caching Proxy. Pour améliorer les performances en minimisant le nombre d'écritures dans le journal, ces agents utilisateur ne sont pas consignés. Par défaut, les journaux du serveur accèdent aux demandes effectuées pour tous les autres agents utilisateur.
Cette directive permet de spécifier une icône à utiliser pour l'alignement des en-têtes au niveau des listes de répertoires qui sont renvoyées lorsque le serveur joue le rôle d'un proxy pour les demandes FTP. Les icônes apparaissent en regard des fichiers associés pour aider les utilisateurs à les différencier.
L'icône peut être vide ou il peut s'agir d'une icône que vous avez choisie pour qu'elle apparaisse au niveau des en-têtes des listes de répertoires. Pour un bon alignement, l'icône utilisée doit être de la même taille que les autres icônes utilisées dans les listes de répertoires.
AddBlankIcon URL_icône
texte_de_remplacement
Correspond à la dernière partie de l'URL de l'icône. Le serveur ajoute cette valeur à /icons/ pour former la demande d'URL complète. Si la demande concerne un fichier local, le serveur convertit la demande via les directives de mappage. Pour que l'icône soit extraite, les directives de mappage doivent admettre la transmission de la demande.
Si vous utilisez le serveur en tant que proxy, la demande complète doit être constituée d'une URL complète désignant le serveur.
AddBlankIcon logo.gif logo
La valeur par défaut ne spécifie aucun texte de remplacement étant donné que l'icône est vide.
Cette directive permet de spécifier une icône permettant de représenter un répertoire au niveau d'une liste de répertoire.
AddDirIcon URL_icône
texte_de_remplacement
Correspond à la dernière partie de l'URL de l'icône. Le serveur ajoute cette valeur à /icons/ pour former la demande d'URL complète. Si la demande concerne un fichier local, le serveur convertit la demande via les directives de mappage. Pour que l'icône soit extraite, les directives de mappage doivent admettre la transmission de la demande.
Si vous utilisez le serveur en tant que proxy, la demande complète doit être constituée d'une URL complète désignant le serveur. Vous devez mapper l'URL vers un fichier local et vous assurer que les directives de mappage permettent la transmission de l'URL.
AddDirIcon direct.gif DIR
Cette directive permet d'associer des fichiers d'un suffixe particulier à un codage MIME particulier. Cette directive est rarement utilisée.
AddEncoding .extension codage
AddEncoding .qp quoted_printable
AddEncoding .Z x-compress
Cette directive permet de spécifier des icônes pour la représentation de fichiers avec un type de contenu ou de codage MIME spécifique. Le serveur utilise les icônes au niveau des listes de répertoires, y compris les listes de répertoires FTP.
AddIcon URL_icône texte_de_remplacement
modèle_type_MIME
Correspond à la dernière partie de l'URL de l'icône. Le serveur ajoute cette valeur à /icons/ pour former la demande d'URL complète. Si la demande concerne un fichier local, le serveur convertit la demande via les directives de mappage. Pour que l'icône soit extraite, les directives de mappage doivent admettre la transmission de la demande.
Si vous utilisez le serveur en tant que proxy, la demande complète doit être constituée d'une URL complète désignant le serveur. Vous devez mapper l'URL vers un fichier local et vous assurer que les directives de mappage permettent la transmission de l'URL.
AddIcon video_file.m.pm.gif MOV video/*
Plusieurs valeurs par défaut sont définies pour la directive AddIcon dans le fichier de configuration ibmproxy.conf.
La directive AddLang permet traiter des fichiers dotés de formats de langue différents. Vous pouvez l'utiliser pour associer l'extension de fichier à des langues lorsque les demandes sont transmises en local.
Le serveur proxy prend déjà en charge les directives AddType et AddEncoding pour le traitement de fichiers dotés de formats différents. Il ne peut pas prendre en charge le traitement de différents formats basé sur l'en-tête Accept-Language défini dans les demandes. Toutefois, la directive AddLang, qui a été précédemment masquée, fournit un mécanisme pour associer une langue à une extension de fichier.
AddLang .extension-fichier langue qualité
où langue est utilisé pour rechercher les valeurs de l'en-tête Accept-Language et qualité est une valeur à virgule flottante utilisé pour calculer le classement des fichiers mappés.
Par exemple, supposons que les paramètres Addlang suivants sont configurés :
AddLang .en en 1.001
AddLang .de de 1.0
AddLang .en en-us 0.9
Supposons ensuite que les fichiers sample.html.en et sample.html.de se trouvent déjà sur le disque local. La demande suivante est reçue par Caching Proxy :
GET /sample.html HTTP/1.0 Accept-Language: de,en;q=0.5
.....
Lorsque la demande est reçue, le serveur proxy établit un classement pour chaque fichier local mappé en fonction des valeurs définies dans l'en-tête Accept-Language et des définitions indiquées dans les directives AddLang. Le fichier dont le classement est le plus haut est utilisé pour traiter la demande.
Dans l'exemple suivant, le fichier sample.html.en possède le classement suivant :
Le fichier sample.html.de possède le classement suivant :
Si une valeur n'est pas indiquée pour q dans l'en-tête Accept-Language, la valeur par défaut est 1.0.
Cette directive permet de spécifier une icône permettant de représenter un répertoire parent au niveau des listes de répertoires.
AddParentIcon URL_icône texte_de_remplacement
Correspond à la dernière partie de l'URL de l'icône. Le serveur ajoute cette valeur à /icons/ pour former la demande d'URL complète. Si la demande concerne un fichier local, le serveur convertit la demande via les directives de mappage. Pour que l'icône soit extraite, les directives de mappage doivent admettre la transmission de la demande.
Si vous utilisez le serveur en tant que proxy, la demande complète doit être constituée d'une URL complète désignant le serveur. Vous devez mapper l'URL vers un fichier local et vous assurer que les directives de mappage permettent la transmission de l'URL.
AddParentIcon parent.gif UP
AddParentIcon dir-up.gif UP
Cette directive permet d'associer des fichiers ayant un suffixe particulier à un type/sous-type MIME. Vous pouvez avoir plusieurs occurrences de cette directive dans votre fichier de configuration. Le serveur fournit des valeurs par défaut pour les suffixes les plus fréquemment utilisés.
AddType .type d'extension/code sous-type [qualité[ jeu de caractères]]
Toute autre valeur de codage subit le même traitement que le codage binaire et est transmise dans des en-têtes MIME en tant qu'en-tête MIME de codage de contenu. Les codages 7bit et 8bit ne sont pas transmis dans des en-têtes MIME.
AddType .ps application/postscript 8bit 1.0
AddType *.* application/binary binary 0.3
AddType .bin application/octet-stream binary 0.8
Plusieurs paramètres par défaut pour la directive AddType sont contenus dans le fichier de configuration (ibmproxy.conf).
Cette directive permet de spécifier une icône pour la représentation de fichiers dotés d'un type de fichier inconnu au niveau d'une liste de répertoire.
AddUnknownIcon URL_icône texte_de_remplacement
Correspond à la dernière partie de l'URL de l'icône. Le serveur ajoute cette valeur à /icons/ pour former la demande d'URL complète. Si la demande concerne un fichier local, le serveur convertit la demande via les directives de mappage. Pour que l'icône soit extraite, les directives de mappage doivent admettre la transmission de la demande.
Si vous utilisez le serveur en tant que proxy, la demande complète doit être constituée d'une URL complète désignant le serveur. Vous devez mapper l'URL vers un fichier local et vous assurer que les directives de mappage permettent la transmission de l'URL.
AddUnknownIcon saywhat.gif unknown
Cette directive permet de spécifier un port pouvant être utilisé par les administrateurs pour accéder aux pages de statut du serveur ou aux formulaires de configuration. Les demandes vers ce port ne sont pas placées en file d'attente avec les autres demandes en entrée au niveau du port standard défini par la directive Port. Cependant, les demandes au niveau de l'élément AdminPort passent par les mêmes règles de mappage de demande et de contrôle d'accès (Pass, Exec, Protect, par exemple).
AdminPort numéro_port
AdminPort 2001
AdminPort 8008
Cette directive permet de spécifier si les fichiers renvoyés par le serveur d'origine et pour lesquels il est indiqué qu'ils ne peuvent être mis en mémoire cache doivent l'être malgré tout. Les fichiers ne pouvant être placés en mémoire cache, et qui le sont malgré tout selon cette directive, sont marqués à revalider. Chaque fois que le ficher est demandé, le serveur proxy envoie une demande If-Modified-Since au serveur d'origine afin de valider à nouveau la réponse avant qu'elle ne soit traitée par la mémoire cache. A l'heure actuelle, les seuls fichiers concernés par cette directive sont les réponses provenant du serveur d'origine contenant un en-tête cache-control : no cache/xph>. Cette directive peut être spécifiée plusieurs fois.
AggressiveCaching modèle_URL
AggressiveCaching http://www.hôtea.com/*
AggressiveCaching http://www.hôteb.com/*
Par assurer la compatibilité en amont, la syntaxe précédente de cette directive (AggressiveCaching {on | off}) est désormais traitée comme suit :
Aucune
Cette directive permet de spécifier des URL pour lesquelles Caching Proxy doit ajouter des caractères de saut de ligne et de retour chariot à la fin du corps d'une demande POST. Cette directive peut être spécifiée plusieurs fois.
appendCRLFtoPost modèle_URL
appendCRLFtoPost http://www.hosta.com/
Aucune
Cette directive permet de spécifier le tableau de la mémoire cache à distance à partager par les serveurs.
ArrayName nom_tableau
Aucune
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de l'étape d'authentification du processus de demande de serveur. Ce code est exécuté en suivant le schéma d'authentification. Seule l'authentification BASIC est prise en charge.
Authentication type
/chemin/fichier:nom_fonction
Authentication (BASIC) /ics/api/bin/icsextpgm.so:basic_authentication
Aucune
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de l'étape d'autorisation du processus de demande de serveur. Ce code vérifie que l'objet demandé peut être transmis au client.
Authorization modèle_demande /chemin/fichier:nom_fonction
Authorization /index.html /api/bin/icsextpgm.so:auth_url
Aucune
Cette directive permet d'activer ou de désactiver la régénération de la mémoire cache. Si cette fonction est activée, la mémoire cache est automatiquement régénérée. Si elle est désactivée, l'agent de la mémoire cache n'est pas appelé et tous ses paramètres sont ignorés. Si vous lancez l'agent de la mémoire cache en utilisant une autre méthode, par exemple en exécutant un travail cron sur des systèmes Linux et UNIX, désactivez cette directive.
AutoCacheRefresh {on | off}
AutoCacheRefresh On
Sur un système connecté à plusieurs réseaux, cette directive indique si le serveur contrôle une seule adresse réseau. Si la valeur correspond à On, le serveur se connecte à l'adresse IP indiquée dans la directive Hostname au lieu de se connecter à toutes les adresses locales.
Si cette directive n'est pas spécifiée, le serveur est lié au nom d'hôte par défaut.
Si vous modifiez cette directive, vous devez arrêter manuellement le serveur puis le redémarrer. La modification n'est pas prise en compte si vous redémarrez le serveur sans l'arrêter. (Voir Démarrage et arrêt de Caching Proxy.)
BindSpecific {on | off} [OutgoingSrcIp adresse_ip | nom_hôte]
BindSpecific Off
Cette directive permet de spécifier la taille (en octets) des blocs dans l'unité de mise en mémoire cache. La valeur par défaut est de 8192. Comme il s'agit de la seule taille prise en charge, ne la modifiez pas. Pour plus d'informations, voir la section de référence htcformat, commande.
BlockSize taille
Par défaut, le fichier de configuration ne contient pas de valeur pour ce paramètre. (La valeur par défaut est de 8192.)
Cette directive permet d'identifier le chemin et le nom du fichier dans lequel le serveur doit stocker un journal des accès à la mémoire cache du proxy. Cette directive est valide uniquement si le serveur est exécuté en tant que proxy. Pour plus d'informations, voir CacheRefreshTime — Indique à quel moment démarrer l'agent de la mémoire cache.
Pour activer la consignation des demandes adressées à la mémoire cache du proxy, la directive Caching doit avoir la valeur ON, et des valeurs doivent être définies pour les directives CacheMemory et CacheAccessLog. Vous pouvez également définir une ou plusieurs unités de mémoire cache à l'aide de la directive CacheDev.
La valeur de CacheAccessLog peut être soit un chemin absolu soit un chemin relatif d'accès à la racine du serveur. (Des exemples sont fournis.)
CacheAccessLog chemin/fichier
CacheAccessLog /absolute/path/logfile
CacheAccessLog /logs/logfile
Cette directive permet de spécifier l'algorithme de mémoire cache utilisée par le serveur lors de la récupération d'espace.
CacheAlgorithm {bandwidth | responsetime | blend}
CacheAlgorithm bandwidth
Cette directive permet de spécifier si les noms de fichier de mémoire cache générés dépendent de l'URL d'entrée de la demande.
Si la directive a la valeur on, les noms de fichier de mémoire cache dépendent de l'URL d'entrée. Si la directive est associée à la valeur off, l'URL d'entrée transite d'abord via tous les plug-ins de conversion de nom applicables, les règles MAP et les règles PROXY, puis le nom de fichier de mémoire cache généré est basé sur l'URL résultante.
CacheByIncomingUrl {on | off}
CacheByIncomingURL off
Cette directive permet de spécifier la durée de conservation des fichiers mis en mémoire cache. Lorsque la récupération de place s'exécute, le serveur supprime les fichiers en mémoire cache qui ont dépassé cette durée, et ce quelle que soit la date d'expiration de ces fichiers. Chaque fois qu'un fichier ayant dépassé la durée fixée est demandé, le serveur valide à nouveau le fichier avant de le fournir afin de garantir sa validité.
CacheClean spécification_durée
CacheClean 2 semaines
CacheClean 1 mois
Cette directive permet de définir une heure d'expiration par défaut pour les fichiers auxquels le serveur n'a pas attribué d'en-tête Expires ou Last-Modified. Indiquez un modèle d'URL et une heure d'expiration pour les fichiers ayant des URL correspondant au modèle. Vous pouvez avoir plusieurs occurrences de cette directive dans le fichier de configuration. Incluez une directive séparée pour chaque modèle. Le modèle d'URL doit inclure le protocole. Indiquez la valeur de temps en utilisant n'importe quelle combinaison de mois, semaines, jours et heures.
CacheDefaultExpiry modèle_URL
heure_expiration
CacheDefaultExpiry ftp:* 1 jour
CacheDefaultExpiry gopher:* 2 jours
CacheDefaultExpiry http:* 0 jour
Cette directive permet de spécifier une unité de mise en mémoire cache. Vous pouvez spécifier soit un fichier soit une partition de disque. Sur des plateformes AIX, vous pouvez spécifier un volume logique. (Si vous n'utilisez pas de mémoire cache, la mise en mémoire cache sur disque offre les meilleures performances.)
Il est à noter que les unités de mise en mémoire cache doivent être préparées avant de pouvoir être spécifiées. Pour préparer une unité de mise en mémoire cache, formatez-la à l'aide de la commande htcformat. Pour plus d'informations, voir htcformat, commande.
Vous pouvez spécifier plusieurs unités de mise en mémoire cache. Chaque unité sera associée aux mêmes valeurs CacheMemory et BlockSize. Cependant, chaque unité de mise en mémoire cache représente une surcharge de mémoire sur le serveur proxy d'environ 8 Mo. Un petit nombre d'unités de grande taille est plus efficace que de nombreuses unités de petite taille. Pour une meilleure efficacité, utilisez un disque entier en tant que partition de taille importante. Vous trouverez des informations détaillées sur la mise en mémoire cache à la section Optimisation des performances du cache disque.
CacheDev {partition_disque_brut | fichier}
AIX : CacheDev /dev/rlv02
HP-UX : CacheDev /dev/rdsk/c1t15d0
Linux : CacheDev /opt/IBMWTE/filecache1
Solaris : CacheDev /dev/rdsk/clt3d0s0
Windows : CacheDev \\.\E:
Aucune
Cette directive permet d'indiquer si le serveur doit renvoyer les fichiers mis en mémoire cache qui ont expiré. Entrez Off pour la valeur si vous voulez que le serveur puisse renvoyer les fichiers ayant expiré. Utilisez la valeur par défaut On si vous voulez que le proxy cherche dans le serveur d'origine une version plus récente lorsque le client demande un fichier ayant expiré. En principe, les administrateurs ne souhaitent pas que le serveur renvoie des fichiers expirés, sauf s'ils travaillent en mode démonstration et que le contenu renvoyé par le serveur ne présente aucun intérêt en lui-même.
CacheExpiryCheck {on | off}
CacheExpiryCheck On
Cette directive permet d'indiquer la taille maximale des fichiers à mettre en mémoire cache. Les fichiers supérieurs à cette taille ne seront pas mis en mémoire cache. La valeur peut être spécifiée en octets (O), kilooctets (K) ou en gigaoctets (G). Vous pouvez éventuellement insérer un caractère d'espacement entre le nombre et la valeur (O, K, M, G).
CacheFileSizeLimit maximum {B | K | M | G}
CacheFileSizeLimit 4000 K
Cette directive permet d'indiquer la valeur à utiliser pour calculer les dates d'expiration pour des URL spécifiques ou pour toutes les URL correspondant à un modèle.
Les serveurs HTTP attribuent fréquemment une heure de dernière modification à un fichier mais non une date d'expiration. De même, les fichiers FTP peuvent avoir un horodatage de dernière modification mais ne possèdent pas d'heure d'expiration. Caching Proxy calcule une heure d'expiration pour ces fichiers en fonction de l'heure de dernière modification. Il utilise l'heure de dernière modification pour déterminer depuis combien de temps le fichier a été modifié et il multiplie cette durée par la valeur de la directive CacheLastModifiedFactor. Le résultat de ce calcul correspond à la durée de vie du fichier ou la période pendant laquelle il est encore valide.
Vous pouvez également entrer off ou -1 pour désactiver la directive et ne pas calculer de date d'expiration. Le serveur proxy lit les directives CacheLastModifiedFactor dans l'ordre dans lequel elles apparaissent dans le fichier de configuration. Il utilise la première directive qu'il peut appliquer au fichier mis en mémoire cache.
CacheLastModifiedFactor url facteur
CacheLastModifiedFactor *://hôtea/* off
CacheLastModifiedFactor ftp://hôteb/* 0.30
CacheLastModifiedFactor ftp://* 0.25
CacheLastModifiedFactor http://* 0.10
CacheLastModifiedFactor * 0.50
CacheLastModifiedFactor http://*/ 0.10
CacheLastModifiedFactor http://*.htm* 0.20
CacheLastModifiedFactor http://*.gif 1.00
CacheLastModifiedFactor http://*.jpg 1.00
CacheLastModifiedFactor http://*.jpeg 1.00
CacheLastModifiedFactor http://*.png 1.00
CacheLastModifiedFactor http://*.tar 1.00
CacheLastModifiedFactor http://*.zip 1.00
CacheLastModifiedFactor http:* 0.15
CacheLastModifiedFactor ftp:* 0.50
CacheLastModifiedFactor * 0.10
La valeur par défaut 0.14 fait que les fichiers modifiés la semaine précédente expirent en un jour.
Cette directive permet d'indiquer s'il faut mettre en mémoire cache les URL provenant d'hôtes du même domaine que le proxy. Les sites locaux du réseau interne ne nécessitent généralement pas de mise en mémoire cache car la largeur de bande interne est suffisante pour charger les URL rapidement. En ne mettant pas en mémoire cache les sites locaux, vous conservez de l'espace en mémoire cache pour les URL pour lesquelles le temps d'extraction est plus long.
CacheLocalDomain {on | off}
CacheLocalDomain on
Si le serveur dorsal est en mesure de renvoyer différentes langues aux clients pour la même adresse URL, utilisez cette directive pour prendre en charge la mise en cache de différentes langues pour une même adresse. Cette directive permet à Caching Proxy de vérifier la préférence de langue définie dans les requêtes par rapport à la langue de la réponse mise en cache.
Lorsque l'option CacheMatchLanguage est activée, le système compare la préférence de langue indiquée dans l'en-tête Accept-Language de la requête à la langue du contenu disponible en cache. Caching Proxy compare l'écart des préférences. Si l'écart de préférences est inférieur à la limite indiquée, le système renvoie la copie en mémoire cache ; Dans le cas contraire, le serveur proxy réachemine la demande au serveur dorsal pour obtenir une copie récente dans la langue demandée.
CacheMatchLanguage {on | off} limite-distance-préférence-langue id-spécial-pour-toutes-langues
Voici un exemple de configuration de la directive, de l'objet en cache et de la demande.
CacheMatchLanguage On 0.2
Si l'objet en cache correspond au chinois simplifié (zh_cn) et que la requête est :
GET / HTTP/1.1
...
Accept-Language: en_US;q=1.0, zh_cn;q=0.7, ja;q=0.3
....
Dans cet exemple, l'utilisateur demande une page en anglais (associée au code et au niveau en_US/1.0), en chinois simplifié (associée au code et au niveau zh_cn/0.7), puis en japonais (associée au code et au niveau ja/0.3). L'objet mis en cache est en chinois simplifié. L'écart de préférences entre le niveau optimal prévu et le niveau de langue disponible est 1.0 - 0.7 = 0.3. Comme la directive CacheMatchLanguage est associée à la valeur 0.2, le serveur proxy demande au serveur une nouvelle copie de cette adresse URL au lieu de renvoyer l'objet disponible en cache.
Si le serveur n'indique pas de page spécifique ni de valeur special-id-for-all-lang dans l'en-tête Content-Language lors du renvoi de la réponse, le serveur proxy ne prend pas en compte la préférence de langue et renvoie la copie disponible en cache.
CacheMatchLanguage off
Cette directive permet de définir la durée maximale pendant laquelle les fichiers peuvent rester en mémoire cache. La durée de vie d'un fichier mis en mémoire cache correspond à la durée pendant laquelle il peut être transmis à partir de la mémoire cache sans vérification de l'origine des mises à jour. Dans certains cas, la durée de vie calculée pour un fichier mis en mémoire cache peut être supérieure à la durée pendant laquelle vous désirez conserver ce fichier. La durée de vie du fichier, soit spécifiée par l'origine, soit calculée par Caching Proxy, ne peut pas être supérieure à la limite spécifiée par la directive CacheMaxExpiry.
Vous pouvez avoir plusieurs occurrences de cette directive dans le fichier de configuration. Incluez une directive séparée pour chaque modèle.
CacheMaxExpiry URL durée
CacheMaxExpiry ftp:* 1 mois
CacheMaxExpiry http://www.santaclaus.np/* 2 jours 12 heures
CacheMaxExpiry 1 mois
Cette directive permet de spécifier la quantité de mémoire à associer à la mémoire cache. Pour optimiser les performances des mémoires cache sur disque, un minimum de 64 Mo de mémoire cache est recommandé pour la prise en charge de l'infrastructure de mise en cache, y compris l'index de la mémoire cache. L'index de la mémoire cache augmente à mesure que la taille de la mémoire cache augmente, e sorte que l'espace mémoire nécessaire pour stocker l'index s'accroît également. Une mémoire cache de 64 Mo suffit pour prendre en charge l'infrastructure de mise en cache et pour stocker un index de mémoire cache pour une mémoire cache sur disque d'environ 6,4 Go. Les mémoires cache sur disque plus volumineuses doivent avoir une fois et demie la taille de la mémoire cache.
Si la mise en mémoire cache est utilisée, ce paramètre doit inclure la mémoire cache plus la quantité de mémoire nécessaire pour l'index de la mémoire cache.
La valeur maximale conseillée pour ce paramètre est 1600 Mo. Cette limite est déterminée par le fait que Caching Proxy, en tant qu'application 32 bits, peut utiliser 2 Go de mémoire au maximum. Si la quantité de mémoire nécessaire pour la mémoire cache plus celle utilisée pour le traitement des routines approchent ou dépassent 2 Go, Caching Proxy ne fonctionnera pas correctement.
La quantité peut être spécifiée en octets (b), kilo-octets (K) et gigaoctets (G).
CacheMemory quantité {B | K | M | G}
CacheMemory 64 M
Cette directive permet de spécifier les URL des fichiers dont la date d'expiration doit être ignorée. Certains sites définissent une date d'expiration des fichiers antérieure à leur durée de vie, ce qui oblige le serveur à demander le fichier plus fréquemment. La directive CacheMinHold permet de conserver le fichier expiré en mémoire cache pendant la durée indiquée avant de le redemander. Cette directive peut être spécifiée plusieurs fois.
CacheMinHold http://www.cachebusters.com/* 1 heure
Aucune
Cette directive permet d'indiquer si le serveur proxy doit récupérer les fichiers à partir de serveurs distants. La valeur par défaut (Off) indique que le serveur proxy doit extraire les fichiers se trouvant sur des serveurs distants. La valeur On impose l'exécution du serveur en mode de mémoire cache autonome. De cette manière, le serveur peut renvoyer uniquement les fichiers déjà stockés dans sa mémoire cache. Généralement, vous attribuez également la valeur Off à la directive CacheExpiryCheck lors de l'exécution du serveur avec ce mode.
L'exécution du serveur en mode mémoire cache autonome peut être utile si vous utilisez le serveur pour des démonstrations. Si vous savez que tous les fichiers que vous voulez utiliser pour la démonstration sont présents en mémoire cache, vous n'avez pas besoin de connexion réseau.
CacheNoConnect {on | off}
CacheNoConnect Off
Cette directive permet de définir que seuls les fichiers ayant des URL correspondant à un modèle donné doivent être mis en mémoire cache. Vous pouvez avoir plusieurs occurrences de cette directive dans le fichier de configuration. Incluez une directive séparée pour chaque modèle. Le modèle d'URL doit inclure le protocole. Si aucune valeur n'est définie pour cette directive, toute URL ne répondant à aucune directive NoCaching peut être placée en mémoire cache. Si le fichier de configuration ne contient ni directive CacheOnly ni directive NoCaching, n'importe quelle URL peut être mise en mémoire cache.
CacheOnly modèle_URL
CacheOnly http://vraitruc/*
Aucune
Cette directive permet de spécifier les URL pour lesquelles les réponses aux demandes de requête doivent être mises en mémoire cache. Si la valeur PUBLIC modèle_URL est utilisée, les réponses aux demandes GET contenant un point d'interrogation dans l'URL seront mises en mémoire cache si le serveur d'origine comprend un en-tête cache-control: public et que la réponse peut être mise en mémoire cache. Si la valeur ALWAYS modèle_URL est spécifiée, les réponses aux demandes GET contenant un point d'interrogation dans l'URL sont stockées dans la mémoire cache à condition que la réponse puisse être mise en mémoire cache.
Cette directive peut être spécifiée plusieurs fois.
CacheQueries {ALWAYS | PUBLIC}
modèle_URL
CacheQueries ALWAYS http://www.hosta.com/*
CacheQueries PUBLIC http://www.hostb.com/*
Aucune
Cette directive permet d'indiquer à quel moment effectuer une vérification auprès du serveur d'origine pour déterminer si un fichier en mémoire cache a changé.
Bien que CacheClean semble être similaire à cette directive, il existe une différence. CacheRefreshInterval fait uniquement en sorte que le proxy valide à nouveau le document avant de l'utiliser alors que CacheClean fait en sorte que le fichier soit supprimé de la mémoire cache après une durée définie.
CacheRefreshInterval modèle_URL période
CacheRefreshInterval
durée
CacheRefreshInterval *.gif 8 heures
CacheRefreshInterval 1 semaine
CacheRefreshInterval 2 semaines
Cette directive permet de spécifier le moment du démarrage de l'agent de la mémoire cache. Vous pouvez démarrer l'agent de la mémoire cache à un moment spécifique.
CacheRefreshTime HH:MM
CacheRefreshTime 03:00
La directive CacheTimeMargin détermine si la durée de vie minimale d'un fichier est suffisante pour que ce dernier soit mis en mémoire cache.
Caching Proxy calcule une heure d'expiration pour chaque fichier. S'il est peu probable qu'une autre demande soit reçue concernant le fichier avant expiration du délai, Caching Proxy considère que la durée de vie du fichier est trop courte pour justifier la mise en mémoire cache de ce dernier. Par défaut, Caching Proxy ne met pas en mémoire cache les fichiers dont la durée de vie est inférieure à 10 minutes. Si la mémoire cache ne se rapproche pas de sa capacité maximale, laissez la valeur initiale pour la directive. Si la mémoire cache est proche de la saturation, vous pouvez envisager d'augmenter la valeur de la durée de vie minimale.
CacheTimeMargin durée_de_vie_minimum
CacheTimeMargin 10 minutes
Cette directive permet de définir la durée maximale pendant laquelle conserver en mémoire cache les fichiers non utilisés et ayant des URL correspondant à un modèle donné. Le serveur supprime les fichiers non utilisés ayant des URL correspondant au modèle une fois qu'ils ont été mis en mémoire cache pour la durée spécifiée, quelle que soit la date d'expiration. Vous pouvez utiliser plusieurs occurrences de cette directive dans le fichier de configuration. Incluez une directive séparée pour chaque modèle. Le modèle d'URL doit inclure le protocole. Indiquez la valeur de temps en utilisant n'importe quelle combinaison de mois, semaines, jours et heures.
CacheUnused modèle_URL
durée
CacheUnused ftp:* 3 semaines
CacheUnused gopher:* 3 jours 12 heures
CacheUnused * 4 semaines
CacheUnused ftp:* 3 days
CacheUnused gopher:* 12 hours
CacheUnused http:* 2 days
Cette directive permet d'activer la mise en mémoire cache des fichiers. Lorsque la mise en mémoire cache est activée, le serveur proxy place les fichiers extraits des autres serveurs dans une mémoire cache locale. Le serveur proxy répond ensuite aux demandes suivantes pour les mêmes fichiers sans avoir à les extraire d'autres serveurs.
Caching {on | off}
Caching On
Cette directive permet de spécifier au bout de combien de temps les fichiers journaux sont compressés. Lorsque les journaux sont plus anciens que la valeur définie pour CompressAge, ils sont compressés. Si CompressAge a la valeur 0, les journaux ne sont jamais compressés. Les journaux de la journée en cours et de la veille ne sont jamais compressés.
CompressAge nombre_de_jours
CompressAge 1
Cette directive permet de créer une commande qui identifie l'utilitaire de compression permettant de compacter les journaux et transmet les paramètres à cet utilitaire. Indiquez le chemin des journaux archivés.
L'utilitaire de compression doit être installé dans un répertoire se trouvant dans le chemin d'accès pour cette machine.
CompressCommand commande
CompressCommand tar -cf /logarchs/log%%DATE%%.tar %%FICHIERSJOURNAUX%% ;
gzip /logarchs/log%%DATE%%.tar
CompressCommand tar -cf /logarchs/log%%DATE%%.tar %%FICHIERSJOURNAUX%% ;
compress /logarchs/log%%DATE%%.tar
CompressCommand zip -q /logarchs/log%%DATE%%.zip %%FICHIERSJOURNAUX%%
CompressCommand pkzip -q d:\logarchs\log%%DATE%%.tar %%FICHIERSJOURNAUX%%
Aucune
Cette directive permet de spécifier le moment de suppression d'un journal après sa compression. Lorsqu'un journal est antérieur au nombre de jours définis pour CompressDeleteAge, il est supprimé. Si CompressDeleteAge a la valeur 0, ou si sa valeur est inférieure à celle définie pour la directive CompressAge, aucun journal n'est supprimé.
CompressDeleteAge nombre_de_jours
CompressDeleteAge 7
Cette directive permet de spécifier le type de contenu de la réponse HTTP à compresser.
Le compression HTTP permet de réduire la charge du réseau et augmente les performances du serveur proxy. En cas d'activation de la fonction de filtre de compression, si le navigateur accepte la compression HTTP et si la réponse HTTP n'est pas actuellement compressée, Caching Proxy compresse la réponse HTTP et renvoie le contenu compressé au navigateur.
Vous pouvez activer la fonction de filtre de compression en ajoutant les deux directives suivantes au fichier ibmproxy.conf :
CompressionFilterEnable /opt/ibm/edge/cp/lib/mod_z.sl
CompressionFilterAddContentType type-1[,type-n]
CompressionFilterEnable /opt/ibm/edge/cp/lib/mod_z.so
CompressionFilterAddContentType type-1[,type-n]
CompressionFilterEnable C:\Program Files\IBM\edge\cachingproxy\cp\Bin\mod_z.dll
CompressionFilterAddContentType type-1[,type-n]
La bibliothèque mod_z référencée dans la directive CompressionFilterEnable est la version dynamique de zlib1.1.4.
La variable type-n représente n'importe quelle valeur de l'en-tête Content-Type (par exemple, text/html ou image/bmp).
Aucune
Cette directive permet d'activer le filtre de compression de façon qu'il compresse les réponses HTTP à partir du serveur dorsal ou à partir de la mémoire cache du serveur proxy.
Pour des exemples d'utilisation de cette directive, voir CompressionFilterAddContentType — Indique le type de contenu de la réponse HTTP à compresser.
Aucune
Cette directive permet d'indiquer le nom et l'emplacement d'un fichier de configuration supplémentaire. Les directives se trouvant dans le fichier de configuration spécifié sont traitées après le fichier de configuration en cours.
Aucune
Utilisez cette directive pour définir le nombre d'unités d'exécution de connexions à utiliser pour la gestion des connexions
ConnThreads numéro
ConnThreads 5
Cette directive permet d'indiquer la proportion du fichier demandé devant être transférée pour que Caching Proxy puisse créer le fichier de mémoire cache même si la connexion client est terminée. Les valeurs admises pour cette variable sont comprises entre 0 et 100.
Par exemple, si ContinueCaching 75 est utilisé, Caching Proxy continue le transfert du fichier à partir du serveur de contenu et génère le fichier de mémoire cache si 75 % ou plus du fichier a déjà été transféré avant que Caching Proxy ne détecte que la connexion client est terminée.
ContinueCaching pourcentage
ContinueCaching 75
Cette directive permet de fournir au proxy les informations nécessaires au filtrage des URL en fonction du contenu, notamment les informations de service de classification. Cette directive peut être spécifiée plusieurs fois.
DefinePicsRule "nom_filtre" {
DefinePicsRule "Exemple RSAC" {
Cette directive permet d'associer une configuration de protection par défaut à des demandes correspondant à un modèle.
DefProt modèle_demande nom_configuration [ FOR adresse_IP_serveur | nom_hôte]
La protection n'est pas activée pour les demandes correspondant au modèle sauf si la demande correspond également au modèle d'une directive Protect suivante. Pour plus d'informations sur l'utilisation de la directive Protect avec Defprot, voir Protect — Active une configuration de protection pour les demandes correspondant à un modèle.
Vous pouvez spécifier une adresse IP (par exemple, FOR 240.146.167.72) ou un nom d'hôte (par exemple, FOR hostA.bcd.com).
Ce paramètre est facultatif. Sans ce paramètre, le serveur utilise la directive pour toutes les demandes quelle que soit l'adresse IP d'où elles proviennent ou le nom d'hôte de l'URL.
Il n'est pas possible d'indiquer de caractère générique pour une adresse IP de serveur.
DefProt /secret/* /server/protect/setup1.acc
DefProt /secret/* SECRET-PROT
DefProt {
AuthType Basic
ServerID restricted
PasswdFile /docs/etc/WWW/restrict.password
GroupFile /docs/etc/WWW/restrict.group
GetMask authors
PutMask authors
}
DefProt /secret/* CustomerA-PROT 0.67.106.79
DefProt /secret/* CustomerB-PROT 0.83.100.45
DefProt /secret/* CustomerA-PROT hôteA.bcd.com
DefProt /secret/* CustomerB-PROT hôteB.bcd.com
Aucune
Cette directive permet d'indiquer si l'agent de la mémoire cache doit attendre entre l'envoi des demandes aux serveurs de destination. La définition d'un délai entre les demandes réduit la charge sur la machine proxy et le lien réseau, ainsi que sur les serveurs de destination. L'absence de délai permet à l'agent de la mémoire cache d'être exécuté à sa vitesse maximale. Dans le cas de connexions Internet lentes, il est conseillé de ne pas définir de délai afin d'exploiter au maximum les possibilités de votre réseau.
DelayPeriod {on | off}
DelayPeriod On
Cette directive permet d'identifier si l'agent de la mémoire cache suivra les liens hypertexte entre les hôtes. Si une URL mise en mémoire cache contient des liens vers d'autres serveurs, le serveur peut ignorer le lien ou le suivre. Si la directive DelveInto a la valeur jamais, cette directive n'est pas appliquée.
DelveAcrossHosts {on | off}
DelveAcrossHosts Off
Cette directive permet d'identifier le nombre de niveaux de liens à suivre lors de la recherche de pages devant être chargées dans la mémoire cache. Si la directive DelveInto a la valeur jamais, cette directive n'est pas appliquée.
DelveDepth
nombre_de_niveaux
DelveDepth 2
Cette directive permet d'indiquer si l'agent de la mémoire cache doit charger les pages liées à des URL en mémoire cache.
DelveInto {toujours | jamais | admin | topn}
DelveInto always
Cette directive permet d'appliquer une image d'arrière-plan aux listes de répertoires générées par le serveur proxy. Les listes de répertoire sont générées lorsque le serveur proxy parcourt les sites FTP.
Définissez un chemin d'accès absolu pour l'image d'arrière-plan. Si l'image se trouve sur un autre serveur, vous devez indiquer une URL complète pour l'image d'arrière-plan. Si aucune image d'arrière-plan n'est utilisée, un arrière-plan blanc s'affiche.
DirBackgroundImage
/chemin/file
DirBackgroundImage /images/corplogo.png
DirBackgroundimage http://www.somehost.com/graphics/embossed.gif
Aucune
Cette directive permet de spécifier si les listes de répertoires doivent inclure le montant exact d'octets des fichiers dont la taille est inférieure à 1 Ko. Si la valeur Off est indiquée, la valeur 1 Ko est attribuée à tous les fichiers dont la taille est inférieure ou égale à 1 Ko.
DirShowBytes {on | off}
DirShowBytes Off
Cette directive permet de spécifier si la distinction doit être faite entre les majuscules et les minuscules lors du tri des noms de fichiers des listes de répertoire.
Si vous indiquez On, les majuscules sont placées avant les minuscules.
DirShowCase {on | off}
DirShowCase On
Cette directive permet de spécifier si les listes de répertoire doivent inclure la date de la dernière modification de chaque fichier.
DirShowDate {on | off}
DirShowDate On
Cette directive permet de spécifier si les listes de répertoires doivent inclure les descriptions des fichiers HTML. Les descriptions proviennent des balises <title> HTML des fichiers.
Les descriptions des listes de répertoire FTP affichent le type MIME si ce dernier peut être déterminé.
DirShowDescription {on | off}
DirShowDescription On
Cette directive permet de spécifier si les listes de répertoires doivent inclure les fichiers cachés se trouvant dans le répertoire. Pour le serveur, chaque fichier dont le nom commence par un point (.) est un fichier caché.
DirShowHidden {on | off}
DirShowHidden On
Cette directive permet de spécifier si le serveur doit inclure des icônes dans les listes de répertoires. Les icônes peuvent être utilisées pour fournir une représentation graphique du type de contenu des fichiers se trouvant dans la liste. Les icônes sont définies par les directives AddBlankIcon, AddDirIcon, AddIcon, AddParentIcon et AddUnknownIcon.
DirShowIcons {on | off}
DirShowIcons On
Cette directive permet de spécifier le nombre maximal de caractères à afficher dans la zone de description de la liste de répertoire.
DirShowMaxDescrLength
nombre_de_caractères
DirShowMaxDescrLength 25
Cette directive permet de définir le nombre maximal de caractères à utiliser pour les noms de fichiers dans les listes de répertoire.
DirShowMaxDescrLength
nombre_de_caractères
DirShowMaxLength 25
Cette directive permet de spécifier le nombre minimal de caractères devant toujours être réservés pour les noms de fichiers des listes de répertoire. Les noms de fichiers du répertoire peuvent dépasser ce nombre. Cependant, la longueur des noms de fichiers ne peut pas dépasser le nombre défini au niveau de la directive DirShowMaxLength.
DirShowMinLength
nombre de caractères
DirShowMinLength 15
Cette directive permet de spécifier si les listes de répertoire doivent mentionner la taille de chaque fichier.
DirShowSize {on | off}
DirShowSize On
Cette directive permet de spécifier les méthodes HTTP que votre serveur n'accepte pas. Pour chaque méthode que le serveur doit rejeter, entrez une directive Disable distincte.
Dans le fichier de configuration par défaut, les méthodes GET, HEAD, OPTIONS, POST et TRACE sont activées et toutes les autres méthodes HTTP prises en charge sont désactivées. Pour désactiver une méthode activée, supprimez-la de la directive Enable et ajoutez-la à la directive Disable.
Disable méthode
Disable PUT
Disable DELETE
Disable CONNECT
Cette directive permet de spécifier les variables d'environnement ne devant pas être héritées par les programmes CGI (hormis les variables d'environnement spécifiques du traitement CGI).
Par défaut, toutes les variables d'environnement sont héritées par des programmes CGI. Utilisez cette directive pour exclure certaines variables d'environnement de l'héritage.
DisInheritEnv variable_environnement
DisInheritEnv PATH
DisInheritEnv LANG
Dans cet exemple, toutes les variables d'environnement sauf PATH et LANG sont héritées par les programmes CGI.
Aucune
Cette directive permet d'indiquer si le serveur doit rechercher les noms d'hôte des clients demandeurs.
DNS-Lookup {on | off}
La valeur utilisée a des incidences sur le comportement du serveur.
DNS-Lookup Off
Cette directive permet de spécifier les méthodes HTTP que votre serveur accepte.
Vous pouvez activer autant de méthodes HTTP que nécessaire. Pour chaque méthode devant être acceptée par le serveur, entrez une directive Enable distincte.
Enable méthode
S'il n'existe aucune directive Service pour une URL spécifique, vous pouvez utiliser la directive Enable pour effectuer une programmation personnalisée pour les méthodes HTTP. Le programme spécifié au niveau de cette directive remplace le traitement standard de cette méthode.
Enable méthode
/chemin/fichierDLL:nom_fonction
Pour des informations sur le format et les options disponibles pour la méthode Enable CONNECT, voir Configuration de l'établissement des tunnels SSL.
Enable GET
Enable HEAD
Enable POST
Enable TRACE
Enable OPTIONS
Utilisez cette directive pour activer l'option de socket TCP NODELAY.
La directive EnableTcpNodelay améliore les performances lorsque des petits paquets IP, par exemple, l'établissement d'une liaison SSL ou une courte réponse HTTP, sont transmis entre le système Caching Proxy et le client. Par défaut, l'option TCP NODELAY est activée pour toutes les sockets.
EnableTcpNodelay {All | HTTP | HTTPS | None}
EnableTcpNodelay All
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur en cas d'erreur. Ce code s'exécute en cas d'erreur afin de fournir des routines d'erreur personnalisées.
Error modèle_demande /chemin/fichier:nom_fonction
Error /index.html /ics/api/bin/icsext05.so:error_rtns
Aucune
Cette directive permet de spécifier le chemin et le nom du fichier dans lequel le serveur doit consigner les erreurs internes.
S'il est en cours d'exécution, le serveur démarre un nouveau fichier journal chaque jour à minuit. Sinon, le serveur démarre un nouveau fichier journal dès que vous le lancez. Lors de la création du fichier, le serveur utilise le nom du fichier spécifié et ajoute un suffixe de date. Le suffixe de date apparaît au format Mmmjjaaaa, où Mmm correspond aux trois premières lettres du mois, jj correspond au jour du mois et aaaa à l'année.
ErrorLog /chemin/répertoire_journaux/nom_fichier
Cette directive permet de spécifier le nom d'un fichier à envoyer au client à l'origine de la demande lorsque le serveur rencontre une erreur particulière. Les directives ErrorPage sont fournies dans le fichier ibmproxy.conf qui associe les mots clés d'erreur aux fichiers de messages d'erreur.
Pour personnaliser les messages d'erreur, vous pouvez modifier les directives ErrorPage afin d'associer les mots clés d'erreur à différents fichiers. Vous pouvez également modifier les fichiers de messages d'erreur. Par exemple, vous pouvez modifier un message afin d'inclure des informations supplémentaires sur la cause de l'incident et suggérer des solutions possibles. Pour des réseaux internes, vous pouvez indiquer un contact que les utilisateurs peuvent appeler.
Les directives ErrorPage peuvent être placées n'importe où dans le fichier de configuration. Lorsque l'erreur se produit, le fichier est traité en fonction des règles de mappage définies dans votre fichier de configuration. C'est pourquoi le fichier à envoyer doit être dans un emplacement accessible via les règles de mappage, comme défini par les directives Fail, Map, NameTrans, Pass, Redirect et Service. Vous devez au moins définir une directive Pass qui permette au serveur de transmettre le fichier de messages d'erreur.
ErrorPage keyword
/chemin/nomfichier.html
ErrorPage scriptstart /HTML/errorpages/scriptstart.htmls
Dans cet exemple, lorsque la condition scriptstart se produit, le serveur envoie le fichier scriptstart.htmls se trouvant dans /HTML/errorpages/ au client.
Le texte HTML suivant est un exemple de ce que peut contenir le fichier :
<HTML>
<HEAD>
<TITLE>Message de la condition SCRIPTSTART</TITLE>
</HEAD>
<BODY>
Impossible de démarrer le programme CGI.
<P>
<A HREF="mailto:admin@websvr.com">Notifiez l'administrateur</A>
de cet incident.
</BODY>
</HTML>
Si la directive qui correspond au chemin dans le fichier de configuration du serveur est PASS /* /wwwhome/*, alors le chemin complet du fichier de messages sera /wwwhome/HTML/errorpages/scriptstart.htmls.
Chaque condition d'erreur est identifiée par un mot clé. Pour savoir quels sont les messages d'erreur à personnaliser, consultez tout d'abord les fichiers de messages d'erreur se trouvant dans /HTML/errorpages fournis avec Caching Proxy. La page d'erreur inclut le numéro de l'erreur, le message par défaut, une explication de la cause et une action de récupération appropriée.
Pour modifier un message d'erreur, procédez de l'une des manières suivantes :
Tous les mots clés d'erreur et les fichiers de messages d'erreur par défaut sont répertoriés dans le fichier ibmproxy.conf, dans la section de la directive ErrorPage. Les fichiers de messages d'erreur incluent le numéro, le mot clé, le message par défaut, l'explication et la réponse utilisateur (action) du message d'erreur.
Le fichier ibmproxy.conf contient de nombreuses valeurs par défaut.
Si vous ne modifiez aucune directive ErrorPage pour une condition d'erreur, la page d'erreur par défaut du serveur de cette condition sera envoyée.
Cette directive permet de spécifier le chemin et le nom du fichier journal des événements. Le journal des événements enregistre des messages d'information à propos de la mémoire cache elle-même.
S'il est en cours d'exécution, le serveur démarre un nouveau fichier journal chaque jour à minuit. Sinon, le serveur démarre un nouveau fichier journal dès que vous le lancez. Lors de la création du fichier, le serveur utilise le nom du fichier spécifié et ajoute un suffixe de date. Le suffixe de date apparaît au format Mmmjjaaaa, où Mmm correspond aux trois premières lettres du mois, jj correspond au jour du mois et aaaa à l'année.
EventLog /chemin/répertoire_journaux/nom_fichier
Cette directive permet de spécifier un modèle pour les demandes à accepter et auxquelles vous répondez en utilisant un programme CGI. Une fois qu'une demande correspond à un modèle d'une directive Exec, la demande n'est pas comparée aux modèles de demandes des directives suivantes.
Exec modèle_demande chemin_programme [adresse_IP_serveur | nom_hôte]
Vous devez utiliser un astérisque (*) en tant que caractère générique dans modèle_demande et chemin-programme. La partie de la demande qui correspond au caractère générique modèle_demande doit commencer par le nom du fichier qui contient le programme CGI.
La demande peut également contenir des données supplémentaires qui sont transmises au programme CGI dans la variable d'environnement PATH_INFO. Les données supplémentaires suivent la première barre oblique se trouvant après le nom de fichier du programme CGI dans la demande. Les données sont transmises en fonction des spécifications CGI.
La directive Exec est récursive et s'applique à tous les sous-répertoires. Vous n'avez pas besoin d'une directive Exec séparée pour chaque répertoire sous cgi-bin et admin-bin.
Vous pouvez spécifier une adresse IP (par exemple, 240.146.167.72) ou un nom d'hôte (par exemple, hostA.bcd.com).
Ce paramètre est facultatif. Sans ce paramètre, le serveur utilise la directive pour toutes les demandes quel que soit le nom d'hôte de l'URL ou l'adresse IP d'où elles proviennent.
Vous ne pouvez pas utiliser de caractères génériques pour spécifier les adresses IP.
Dans cet exemple, si votre serveur reçoit une demande de /idd/depts/plan/c92, il exécute le programme CGI dans /depts/bin/plan.exe en transmettant c92 au programme en tant qu'entrée.
L'exemple ci-dessus utilise le paramètre facultatif d'adresse IP. Si le serveur reçoit des demandes qui commencent par /cgi-bin/, il sert les demandes d'un répertoire différent en fonction de l'adresse IP de la connexion réseau d'où provient la demande. Pour les demandes provenant de 130.146.167.72, le serveur utilise le répertoire /CGI-BIN/customerA. Pour les demandes provenant d'une autre connexion ayant une adresse IP 0.83.100.45, le serveur utilise le répertoire/CGI-BIN/customerB.
Exec /cgi-bin/* /CGI-BIN/customerA/* 130.129.167.72
Exec /cgi-bin/* /CGI-BIN/customerB/* 0.83.100.45
L'exemple ci-dessus utilise le paramètre facultatif de nom d'hôte. Si votre serveur reçoit des demandes commençant par /cgi-bin/, il sert la demande d'un répertoire différent en fonction du nom d'hôte de l'URL. Pour les demandes destinées à hôteA.bcd.com, le serveur utilise le répertoire /CGI-BIN/customerA. Pour les demandes destinées à hôteB.bcd.com, le serveur utilise le répertoire /CGI-BIN/customerB.
Exec /cgi-bin/* /CGI-BIN/customerA/* hôteA.bcd.com
Exec /cgi-bin/* /CGI-BIN/customerB/* hôteB.bcd.com
Exec /cgi-bin/* /opt/ibm/edge/cp/server_root/cgi-bin/*
Exec /admin-bin/* /opt/ibm/edge/cp/server_root/admin-bin/*
Exec server_root/cgi-bin/*
Exec server_root/admin-bin/*
Exec server_root/DOCS/admin-bin/*
Cette directive permet d'exporter le contenu de la mémoire cache vers un fichier de vidage. Cette opération est utile lorsque la mémoire cache est perdue lors du redémarrage ou lors du déploiement de la même mémoire cache sur plusieurs proxys.
ExportCacheImageTo nom_fichier_exportation
Aucune
S'applique aux configurations avec proxy inversé uniquement.
Utilisez cette directive pour configurer Caching Proxy afin qu'il reconnaisse un serveur IBM® WebSphere Application Server (configuré avec un module de carte Caching Proxy) à partir duquel il pourra placer en mémoire cache des ressources dynamiques. Caching Proxy sauvegarde les copies des résultats JSP qui sont aussi stockés dans la mémoire cache dynamique du serveur d'applications. Caching Proxy met en mémoire cache uniquement le contenu d'un serveur IBM WebSphere Application Server dont l'ID groupe correspond à une entrée ExternalCacheManager.
Sachez que pour activer cette fonction, il est également nécessaire d'ajouter une directive Service au fichier de configuration de Caching Proxy. Vous devez aussi effectuer d'autres opérations de configuration sur le serveur d'applications. Pour plus d'informations, voir Stockage en mémoire cache d'un contenu généré dynamiquement.
ExternalCacheManager ID_gestionnaire_cache_externe délai_expiration_maximal
L'entrée suivante définit un gestionnaire de cache externe (un serveur IBM WebSphere Application Server), situé dans le domaine www.xyz.com et dont les ressources expirent dans 20 secondes au plus tard.
ExternalCacheManager IBM-CP-XYZ-1 20 secondes
Aucune
Cette directive permet de spécifier un modèle pour les demandes à ne pas traiter. Une fois qu'une demande correspond à un modèle d'une directive Fail, la demande n'est pas comparée aux modèles de demande des directives suivantes.
Fail modèle_demande [adresse_IP_serveur | nom_hôte]
Vous pouvez utiliser un astérisque en tant que caractère générique dans le modèle. Le caractère tilde (~)placé juste après une barre oblique (/) doit être indiqué explicitement. Vous ne pouvez pas utiliser de caractère générique.
Vous pouvez spécifier une adresse IP (par exemple, 240.146.167.72) ou un nom d'hôte (par exemple, hostA.bcd.com).
Ce paramètre est facultatif. Sans ce paramètre, le serveur utilise la directive pour toutes les demandes quel que soit le nom d'hôte de l'URL ou l'adresse IP d'où elles proviennent.
Il n'est pas possible d'indiquer de caractère générique pour une adresse IP de serveur.
Dans l'exemple ci-dessus, le serveur rejette les demandes commençant par /usr/local/private/.
Fail /usr/local/private/*
Les exemples suivants utilisent le paramètre d'adresse IP facultatif. Le serveur rejette toutes les demandes commençant par /customerB/ si la demande provient d'une connexion réseau dont l'adresse IP est 240.146.167.72. Le serveur rejette toutes les demandes commençant par /customerA/ si la demande provient d'une connexion réseau dont l'adresse IP est 0.83.100.45.
Fail /customerB/* 240.146.167.72
Fail /customerA/* 0.83.100.45
Les exemples ci-après utilisent le paramètre de nom d'hôte facultatif. Le serveur rejette les demandes commençant par /customerB/ si elles sont destinées à hôteA.bcd.com. Le serveur rejette les demandes commençant par /customerA/ si elles sont destinées à hôteB.bcd.com.
Fail /customerB/* hôteA.bcd.com
Fail /customerA/* hôteB.bcd.com
Aucune
Cette directive permet d'activer les codes de chiffrement conformes à la norme FIPS pour le protocole SSLV3 et TLS dans les connexions SSL. Lorsqu'elle est activée, la liste des spécifications de code de chiffrement prises en charge pour SSLV3 (directive V3CipherSpecs) est ignorée. De plus, les spécifications de code de chiffrement TLS autorisées sont définies à la valeur 352F0AFF09FE et les spécifications de code de chiffrement SSLV3 sont définies à la valeur FFFE.
FIPSEnable {on | off}
FIPSEnable off
Cette directive permet d'indiquer au proxy d'utiliser la configuration de SOCKS pour déterminer le type de connexion à établir.
flexibleSocks {on | off}
flexibleSocks on
Cette directive permet d'activer les serveur FTP afin de générer un message de bienvenue ou de description pour un répertoire. Ce message peut être affiché en tant que partie des listes FTP. La directive FTPDirInfo permet de contrôler l'emplacement d'affichage du message.
FTPDirInfo {top | bottom | off}
FTPDirInfo top
Si votre serveur proxy fait partie d'une chaîne de proxys, cette directive permet de spécifier le nom d'un autre proxy devant être contacté par ce serveur pour des demandes FTP. Vous devez préciser une URL complète, y compris la barre oblique de fin (/). Pour plus d'informations sur l'utilisation d'un modèle ou d'un nom de domaine facultatif, voir no_proxy — Spécifie les modèles pour la connexion directe aux domaines.
S'applique aux configurations avec proxy d'acheminement uniquement.
proxy_ftp URL_complète [modèle_ou_nom_domaine]
ftp_proxy http://outer.proxy.server/
Aucune
Cette directive permet de spécifier si les informations de chemin dans l'URL FTP doivent être interprétées comme étant relatives au répertoire de travail de l'utilisateur connecté ou comme étant relatives au répertoire principal.
FTPUrlPath {relative | absolue}
Si la directive FTPUrlPath a la valeur absolue, le répertoire de travail FTP de l'utilisateur connecté doit être inclus dans le chemin de l'URL FTP. Si FTPUrlPath Relative est spécifié, le répertoire de travail FTP de l'utilisateur connecté doit être omis dans le chemin de l'URL FTP. Par exemple, pour accéder au fichier test1.html, contenu dans le répertoire de travail /export/home/user1 pour un utilisateur connecté, les chemins d'URL suivants sont requis, selon la définition de la directive FTPUrlPath :
Aucune
Cette directive permet de spécifier si la récupération de place en mémoire cache est utilisée. Si vous avez activé la mise en mémoire cache, le serveur utilise le processus de récupération de place pour supprimer les fichiers ne devant plus figurer en mémoire cache. Les fichiers sont supprimés en fonction de la date d'expiration et d'autres valeurs de directive de proxy. En principe, si la mise en mémoire cache est utilisée, la récupération de place est utilisée. Dans le cas contraire, l'exploitation de la mémoire cache du proxy est peu performante.
Gc {on | off}
Gc On
Cette directive permet de spécifier une application personnalisée devant être utilisée par le serveur pour le processus de récupération de place.
GCAdvisor /chemin/fichier:nom_fonction
GCAdvisor /api/bin/customadvise.so:gcadv
Cette directive permet de spécifier le pourcentage de la capacité totale de la mémoire cache qui doit être atteint pour déclencher la récupération de place. Ce pourcentage est appelé cote d'alerte. La cote d'alerte est spécifiée en tant que pourcentage de la capacité totale de la mémoire cache. La récupération de place se poursuit jusqu'à ce que la cote d'alerte inférieure soit atteinte. Pour la définir, voir GcLowWater — Spécifie le moment d'arrêt de la récupération de place. Le pourcentage de cote d'alerte peut être compris entre 50 et 95.
GcHighWater pourcentage
GcHighWater 90
Cette directive permet de spécifier le pourcentage de la capacité totale de la mémoire cache qui doit être atteint pour déclencher l'arrêt de la récupération de place. Ce pourcentage est appelé cote d'alerte inférieure. La cote d'alerte inférieure est spécifiée en tant que pourcentage de la capacité totale de la mémoire cache. Elle doit avoir une valeur inférieure à la cote d'alerte. Pour la définir, voir GcHighWater — Indique le moment du lancement de la récupération de place.
GcLowWater pourcentage
GcLowWater 60
Si votre serveur proxy fait partie d'une chaîne de proxys, cette directive permet de spécifier le nom d'un autre proxy devant être contacté par ce serveur pour des demandes Gopher. Vous devez préciser une URL complète, y compris la barre oblique de fin ( /). Pour plus d'informations sur l'utilisation d'un modèle ou d'un nom de domaine facultatif, voir no_proxy — Spécifie les modèles pour la connexion directe aux domaines.
S'applique aux configurations avec proxy d'acheminement uniquement.
gopher_proxy URL_complète [modèle_ou_nom_domaine]
gopher_proxy http://outer.proxy.server/
Aucune
Cette directive permet de spécifier le nom ou le numéro du groupe dans lequel passe le serveur avant d'accéder aux fichiers.
Si vous changez cette directive, vous devez arrêter le serveur puis le redémarrer pour que le changement soit effectif. La modification n'est pas prise en compte si vous vous contentez de redémarrer le serveur. (Voir Démarrage et arrêt de Caching Proxy.)
GroupId {nom_groupe |
numéro_groupe}
AIX : GroupId nobody
HP-UX : GroupId other
Linux :
Solaris : GroupId nobody
Cette directive permet d'indiquer le nom du serveur proxy retourné dans l'entête HTTP
HeaderServerName nom
Aucune
Cette directive permet de spécifier le nom de domaine ou une adresse IP renvoyé aux clients à partir des demandes de fichiers. Si vous spécifiez un nom de domaine, vous devez disposer d'un serveur de nom de domaine capable de résoudre le nom en une adresse IP. Si vous spécifiez une adresse IP, le serveur de nom de domaine n'est pas nécessaire ou accessible.
Hostname {nom | adresse_IP}
Par défaut, cette directive n'est pas spécifiée dans le fichier de configuration d'origine. Si vous ne spécifiez pas cette directive dans le fichier de configuration, la valeur par défaut permet l'acceptation et l'envoi des requêtes définies sur n'importe quel serveur de noms de domaine.
Si votre serveur proxy fait partie d'une chaîne de proxys, cette directive permet de spécifier le nom d'un autre proxy devant être contacté par ce serveur pour des demandes HTTP. Vous devez préciser une URL complète, y compris la barre oblique de fin ( /). Pour plus d'informations sur l'utilisation d'un modèle ou d'un nom de domaine facultatif, voir no_proxy — Spécifie les modèles pour la connexion directe aux domaines.
http_proxy URL_complète[nom_domaine_ou_modèle]
http://outer.proxy.server/
Aucune
Cette directive permet de spécifier si Caching Proxy doit extraire la page d'accueil non sécurisée pour l'URL et tenter d'y trouver des libellés. Si le programme trouve des libellés, ils sont appliqués à la demande sécurisée. Par exemple, si vous demandez https://www.ibm.com/, Caching Proxy extrait http://www.ibm.com/, cherche des libellés et utilise les libellés trouvés pour filtrer https://www.ibm.com/.
Si HTTPSCheckRoot a la valeur off, Caching Proxy n'extrait pas la page d'accueil non sécurisée et ne cherche pas de libellés.
HTTPSCheckRoot {on | off}
HTTPSCheckRoot on
Utilisez cette directive pour indiquer une adresse IP utilisée pour envoyer et recevoir les requêtes ICP. Elle doit figurer dans les directives <MODULEBEGIN> ICP et <MODULEEND>.
ICP_Address adresse_IP
Par défaut, cette directive n'est pas spécifiée dans le fichier de configuration d'origine. Si vous ne spécifiez pas cette directive dans le fichier de configuration, la valeur par défaut permet l'acceptation et l'envoi des requêtes ICP sur n'importe quelle interface.
Utilisez cette sous-directive pour spécifier le nombre d'unités d'exécution générées pour attendre les requêtes ICP. Elle doit figurer dans les directives <MODULEBEGIN> ICP et <MODULEEND>.
ICP_MaxThreads nombre_d'unités_d'exécution
ICP_MaxThreads 5
Si le serveur proxy fait partie d'un cluster ICP, utilisez cette sous-directive pour spécifier les homologues ICP. Il doit figurer dans les directives <MODULEBEGIN> ICP et <MODULEEND>.
Lorsqu'un nouvel homologue est ajouté au cluster ICP, les informations relatives à l'homologue ICP doivent être ajoutées au fichier de configuration de tous les homologues existants. Utilisez une ligne par homologue. Sachez que l'hôte en cours peut également être inclus dans la liste des homologues. A l'initialisation, l'ICP ignore l'entrée de l'hôte en cours. Il est ainsi possible de disposer d'un fichier de configuration unique qui peut être copié vers d'autres machines homologues sans le modifier pour supprimer l'hôte en cours.
ICP_Peer nomhôte port_http port_icp
La ligne ci-après ajoute l'hôte abc.xcompany.com, dont le port du proxy est 80 et le port ICP 3128, en tant qu'hôte.
ICP_Peer abc.xcompany.com 80 3128
Aucune
Utilisez cette sous-directive pour spécifier le numéro du port sur lequel le serveur ICP écoute les requêtes ICP. Elle doit figurer dans les directives <MODULEBEGIN> ICP et <MODULEEND>.
ICP_Port numéro_de_port
ICP_Port 3128
Utilisez cette sous-directive pour spécifier le délai d'attente maximal de Caching Proxy avant la réponse aux requêtes ICP. Ce délai est indiqué en millisecondes. Elle doit figurer dans les directives <MODULEBEGIN> ICP et <MODULEEND>.
ICP_Timeout délai_en_millisecondes
ICP_Timeout 2000
Cette directive permet d'identifier les URL ne devant pas être chargées par l'agent de la mémoire cache. Cette directive est utile lorsque l'agent de la mémoire cache charge des pages liées à partir des URL en mémoire cache. Vous pouvez avoir plusieurs occurrences de la directive IgnoreURL identifiant différentes URL ou masques d'URL. La valeur de cette directive peut contenir des astérisques (*) en tant que caractères génériques pour l'application d'un masque.
IgnoreURL URL
IgnoreURL http://www.yahoo.com/
IgnoreURL http://*.ibm.com/*
IgnoreURL */cgi-bin/*
Cette directive permet de spécifier si vous voulez que le traitement d'instructions côté serveur soit effectué pour les fichiers transmis à partir du système de fichiers ou des programmes CGI. Le traitement des instructions côté serveur est effectué sur les fichiers dont le contenu est de type ext/x-ssi-html. De manière facultative, vous pouvez spécifier que le traitement des instructions côté serveur doit être effectué pour les fichiers dont le type de contenu est text/html. Pour plus d'informations sur les types de contenu, voir AddType — Spécifie le type de données des fichiers ayant une extension particulière.
Vous pouvez utiliser le traitement des instructions côté serveur pour insérer de manière dynamique des informations dans le fichier renvoyé. Ces informations peuvent être la date, la taille d'un fichier, la date de dernière modification d'un fichier, les variables d'environnement côté serveur ou CGI ou des fichiers de type texte. Le traitement des instructions côté serveur est effectué uniquement sur les fichiers émis localement. Caching Proxy n'effectue pas ce type de traitement sur les objets du serveur proxy ou en mémoire cache.
Le traitement des instructions côté serveur fait que le serveur recherche dans vos fichiers des commandes spéciales chaque fois qu'il sert les fichiers. Cette action peut avoir un effet néfaste sur les performances du serveur et peut ralentir le temps de réponse aux clients.
imbeds {on | off | files | cgi | noexec} {SSIOnly | html}
Le serveur vérifie le type de contenu de chaque fichier extrait ainsi que la sortie de chaque programme CGI traité.
Le traitement des instructions côté serveur est normalement effectué uniquement pour les fichiers dont le contenu est de type text/x-ssi/html. Cependant, vous pouvez spécifier que les fichiers dont le contenu est de type text/html soient traités pour les instructions côté serveur.
Pour chaque suffixe, une directive AddType doit être définie avec le type de contenu correct. Si vous utilisez des suffixes autres que .htm ou .html, assurez-vous que la directive AddType est définie avec un contenu de type text/x-ssi/html.
imbeds on SSIOnly
Cette directive permet d'importer le contenu de la mémoire cache à partir d'un fichier de vidage. Cette opération est utile lorsque la mémoire cache est perdue lors du redémarrage ou lors du déploiement de la même mémoire cache sur plusieurs proxys.
ImportCacheImageFrom nom_fichier_importation
Aucune
Cette directive permet de spécifier les variables d'environnement devant être héritées par les programmes CGI (hormis les variables d'environnement spécifiques du traitement CGI).
Si vous n'incluez pas de directive InheritEnv, toutes les variables d'environnement sont héritées par les programmes CGI. Si vous incluez une directive InheritEnv, seules les variables d'environnement spécifiées dans les directives InheritEnv seront héritées en même temps que les variables d'environnement spécifiques de CGI. La directive permet d'initialiser le valeur des variables héritées.
InheritEnv
variable_environnement
InheritEnv PATH
InheritEnv LANG=ENUS
Dans cet exemple, seules les variables d'environnement PATH et LANG seront héritées par les programmes CGI et la variable d'environnement LANG sera initialisée avec la valeur ENUS.
Aucune. Par défaut, toutes les variables d'environnement sont héritées par des programmes CGI.
Cette directive permet de définir le temps attribué à un client pour l'envoi d'une demande après l'établissement d'une connexion au serveur. Un client se connecte tout d'abord au serveur puis envoie une demande. Si le client n'envoie aucune demande dans le laps de temps défini par cette directive, le serveur met fin à la connexion. Spécifiez la durée en combinant des heures, des minutes (ou mn) et des secondes (ou s).
InputTimeout délai
InputTimeout 3 mn 30 s
InputTimeout 2 minutes
Cette directive remplace l'action par défaut du plug-in JunctionRewrite et permet au serveur proxy de corriger certains liens d'URL dans la page HTML. Elle est utilisée avec la directive JunctionRewrite.
S'applique aux configurations avec proxy inversé uniquement.
La directive JunctionReplaceUrlPrefix demande au plug-in JunctionRewrite de remplacer l'URL modèle_url_1 par modèle_url_2 au lieu d'insérer un préfixe au début de l'URL.
JunctionReplaceUrlPrefix modèle_url_1 modèle_url_2
JunctionReplaceUrlPrefix /server1.internaldomain.com/* /server1/*
Dans cet exemple, supposons que l'URL est /server1.internaldomain.com/notes.nsf et que le préfixe est /server1. Au lieu d'insérer le préfixe pour réécrire l'URL et indiquer /server1/server1.internaldomain.com/notes.nsf, le plug-in JunctionRewrite remplace l'URL par /server1/notes.nsf.
Aucune
Cette directive active la routine de réécriture de jonction au sein de Caching Proxy de manière à réécrire les réponses provenant des serveurs d'origine pour garantir que les URL de serveur sont mappés avec le serveur d'origine approprié lors de l'utilisation de jonctions.
S'applique aux configurations avec proxy inversé uniquement.
Le plug-in de réécriture de jonction doit également être activé si vous définissez JunctionRewrite on sans l'option UseCookie. Les jonctions sont définies à l'aide des règles de mappage du proxy.
Consultez les sections Utilisation de cookies à la place de JunctionRewrite et Exemple de plug-in transmogrifier pour l'extension de la fonctionnalité JunctionRewrite pour des informations supplémentaires sur JunctionRewrite.
JunctionRewrite {on | on UseCookie | off}
JunctionRewrite off
Cette directive permet au serveur proxy de réécrire l'option du chemin dans l'en-tête Set-Cookie lorsque le nom du cookie est mis en correspondance. Si la réponse requiert une jonction et que le préfixe de jonction est défini, celui-ci est inséré devant chaque chemin. Cette directive peut être utilisée avec le plug-in JunctionRewrite ou la directive RewriteSetCookieDomain.
S'applique aux configurations avec proxy inversé uniquement.
JunctionRewriteSetCookiePath nom-cookie1 nom-cookie2...
Aucune
Cette directive remplace l'action par défaut du plug-in JunctionRewrite en ignorant la réécriture d'URL si le modèle d'URL est concordant. Elle est utilisée avec le plug-in JunctionRewrite pour corriger certains liens d'URL dans la page HTML. En règle générale, cette directive permet d'ignorer les URL incluant déjà un préfixe.
S'applique aux configurations avec proxy inversé uniquement.
JunctionSkipUrlPrefix modèle_url
JunctionSkipUrlPrefix /server1/*
Dans cet exemple, supposons que l'URL correspond à /server1/notes.nsf etet que le préfixe de jonction est /server1/. Au lieu de réécrire l'adresse URL pour indiquer /server1/server1/notes.nsf, le plug-in JunctionRewrite ignore cette opération et l'adresse URL reste inchangée en apparaissant sous la forme /server1/notes.nsf.
Aucune
Cette directive permet d'éviter un afflux de demandes sur les serveurs dorsaux lorsqu'un objet en cache est revalidé.
Lorsqu'un objet en cache est revalidé avec le contenu sur le serveur dorsal, les demandes portant sur la même ressource sont transmises au serveur dorsal, qui les traitent en tant que proxy. Il arrive parfois que l'afflux de demandes identiques entraîne l'arrêt du serveur dorsal. Vous pouvez éviter que cela se produise en activant cette directive. Lorsque cette directive est activée, une copie périmée de la ressource est renvoyée si cette dernière est mise à jour sur le proxy.
KeepExpired {on | off}
KeepExpired off
Cette directive permet de spécifier le chemin du fichier de la base de données des fichiers de clés utilisée par le serveur pour les demandes SSL. Les fichiers de clés sont générés via l'utilitaire de gestion de clés iKeyman.
KeyRing nom_fichier
Windows : KeyRing C:\Program Files\IBM\edge\cachingproxy\cp\key.kdb
Linux et UNIX : KeyRing /etc/key.kdb
Aucune
Cette directive permet de spécifier le chemin du fichier de mots de passe de la base de données des fichiers de clés. Le fichier de mots de passe est généré via l'utilitaire de gestion de clés iKeyman lors de la création d'un fichier de base de données de fichiers de clés.
KeyRingStash chemin_fichier
Windows : KeyRingStash key.sth
Linux et UNIX : KeyRingStash /etc/key.sth
Aucune
Cette directive permet de contrôler la taille maximale du corps dans les demandes PUT ou POST. Les directives LimitRequest permettent de protéger le proxy d'éventuelles attaques.
La valeur peut être indiquée en kilo-octets (K), mégaoctets (M) ou gigaoctets (G).
LimitRequestBody taille_corps_max {K | M | G}
LimitRequestBody 10 M
Cette directive permet de spécifier le nombre maximal d'en-têtes qui peuvent être envoyées dans des demandes client. Les directives LimitRequest permettent de protéger le proxy d'éventuelles attaques.
LimitRequestFields nombre_en-têtes
LimitRequestFields 32
Cette directive permet de spécifier la longueur maximale de la ligne de demande et la longueur maximale de chaque en-tête dans une demande. Les directives LimitRequest permettent de protéger le proxy d'éventuelles attaques.
La valeur peut être indiquée en octets (B) ou kilo-octets (K).
LimitRequestFieldSize longueur_max_en-tête {B | K}
LimitRequestFieldSize 4096 B
Cette directive permet de spécifier le nombre de connexions client en file d'attente devant être gérées par le serveur avant que ce dernier n'envoie des messages aux clients indiquant que les connexions sont refusées. Ce nombre dépend du nombre de demandes que le serveur peut traiter en l'espace de quelques secondes. Ne définissez pas une valeur supérieure à ce que le serveur peut traiter avant que les clients n'arrivent à expiration et ne mettent fin à la connexion.
ListenBacklog
nombre_de_demandes
ListenBacklog 128
Cette directive permet d'indiquer si les images en ligne doivent être extraites par l'agent de la mémoire cache. Si LoadInlineImages a la valeur on, les images intégrées à une page mise en mémoire cache seront également placées en mémoire cache. Si la valeur est off, les images intégrées ne sont pas mises en mémoire cache.
LoadInlineImages {on | off}
LoadInlineImages on
Cette directive permet d'indiquer à l'agent de la mémoire cache qu'il doit accéder au journal des accès à la mémoire cache de la nuit précédente et charger les URL les plus demandées.
La directive Caching doit avoir la valeur On, et une valeur doit être définie pour la directive CacheAccessLog lorsqu'une valeur est spécifiée pour la directive LoadTopCached.
LoadTopCached nombre_de_pages
LoadTopCached 100
Cette directive permet d'indiquer les URL devant être chargées dans la mémoire cache par l'agent de la mémoire cache. Il est possible d'inclure plusieurs directives LoadURL dans le fichier de configuration, mais les caractères génériques ne sont pas autorisés.
LoadURL url
LoadURL http://www.ibm.com/
Aucune
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de l'étape de personnalisation. Ce code fournit la journalisation ainsi que tout autre traitement effectué une fois la connexion fermée.
Log modèle_demande
/chemin/fichier:nom_fonction
Log /index.html /api/bin/icsextpgm.so:log_url
Aucune
Cette directive permet de spécifier le comportement de la routine d'archivage. Cette directive affecte tous les journaux disposant de paramètres généraux. Elle indique que les journaux doivent être compressés ou purgés, ou qu'aucun traitement ne doit leur être appliqué.
Si vous spécifiez Compress, utilisez les directives CompressAge et CompressDeleteAge pour spécifier le moment de la compression ou de la suppression des journaux. La directive CompressCommand permet d'identifier la commande et les paramètres à utiliser.
Si vous spécifiez Purge, utilisez les directives PurgeAge et PurgeSize pour spécifier le moment de la purge des journaux.
LogArchive {Compress | Purge | aucun}
LogArchive Purge
Cette directive permet de spécifier le format de fichier des fichiers journaux des accès.
LogFileFormat {common | combined}
Par défaut, le format de journal commun NCSA constitue le format d'affichage. Spécifiez combined pour afficher les journaux au format de journal combiné NCSA. Le format combiné ajoute des zones pour l'URL de référence, l'agent utilisateur et le cookie (si ces éléments sont présents dans la demande).
LogFileFormat common
Systèmes Windows uniquement. Lorsque vous exécutez le proxy à partir de la ligne de commande, utilisez cette directive pour afficher les entrées dans le journal des accès. Pour optimiser les performances du serveur, cette directive est associée à la valeur off (désactivé) par défaut.
LogToGUI {on | off}
LogToGUI off
Systèmes Linux et UNIX uniquement. Utilisez cette directive pour spécifier si le serveur doit consigner les demandes d'accès et les erreurs dans le journal système en complément des fichiers journaux et des accès et des erreurs.
LogToSyslog {on | off}
Le fichier journal système doit exister sur le serveur pour que vous puissiez y inscrire des informations de journal d'erreurs. Vous pouvez choisir de consigner uniquement les informations d'accès ou d'erreur ou de consigner ces deux éléments.
Pour envoyer uniquement les informations d'erreur au journal système, ajoutez la ligne suivante au fichier /etc/syslog.conf :
user.err fichier_sortie_syslog_pour_informations_erreur
Pour envoyer uniquement les informations d'accès au journal système, ajoutez la ligne suivante au fichier /etc/syslog.conf :
user.info fichier_info_syslog_pour_informations_accès
Pour envoyer à la fois des informations d'accès et d'erreur au journal système, ajoutez les lignes suivantes au fichier /etc/syslog.conf :
Spécifiez fichier_sortie_syslog et fichier_info_syslog au format suivant :
Après avoir créé le fichier journal système, vous pouvez le redémarrer avec la commande suivante :
kill -HUP 'cat /etc/syslog.pid'
LogToSyslog Off
Cette directive permet de spécifier un modèle pour les demandes que vous voulez modifier en une nouvelle chaîne de demandes. Une fois que le serveur a changé la demande, il utilise la nouvelle chaîne de demandes et la compare aux modèles de demandes des directives suivantes.
La directive Map utilise la chaîne du chemin de demande entrante en vue d'une correspondance avec la règle. Voir aussi MapQuery — Change les demandes ayant abouti en une nouvelle chaîne de demandes, à l'aide de la chaîne de demandes et du chemin de demande pour correspondance avec la règle.
Map modèle_demande nouvelle_demande [adresse_IP_serveur | nom_hôte]
Vous pouvez utiliser un astérisque (*) en tant que caractère générique dans le modèle. Le caractère tilde (~)placé juste après une barre oblique (/) doit être indiqué explicitement. Vous ne pouvez pas utiliser de caractère générique.
Vous pouvez spécifier une adresse IP (par exemple, 240.146.167.72) ou un nom d'hôte (par exemple, hostA.raleigh.ibm.com).
Ce paramètre est facultatif. Sans ce paramètre, le serveur utilise la directive pour toutes les demandes quel que soit le nom d'hôte de l'URL ou l'adresse IP d'où elles proviennent.
Il n'est pas possible d'indiquer de caractère générique pour une adresse IP de serveur.
Map /truc/* /bon/truc/*
Map /truc/*
/clientA/bon/truc/* 240.146.167.72
Map /truc/* /clientB/bon/truc/* 0.83.104.45
Map /truc/* /clientA/bon/truc/* hôteA.bcd.com
Map /truc/* /clientB/bon/truc/* hôteB.bcd.com
Aucune
Cette directive permet de spécifier un modèle pour les demandes que vous voulez modifier en une nouvelle chaîne de demandes. Une fois que le serveur a changé la demande, il utilise la nouvelle chaîne de demandes et la compare aux modèles de demandes des directives suivantes.
La fonctionnalité de la directive est presque la même que celle de la règle Map (Map — Change les demandes ayant abouti en une nouvelle chaîne de demandes, à l'aide de la chaîne du chemin de demande pour correspondance avec la règle). Toutefois, pour gérer une URL avec une chaîne de demandes, MapQuery utilise à la fois le chemin et la chaîne de demandes pour la correspondance avec la règle. Si l'URL entrante est mise en correspondance sur une règle MapQuery, l'URL convertie servira à la correspondance par rapport au reste des règles.
MapQuery peut également convertir une URL avec une chaîne de demandes à une autre URL avec un autre chemin ou une autre chaîne de demandes. Toutefois, comme toutes les autres directives de mappage utilisent uniquement le chemin de demandes, la chaîne de demandes modifiée ne sera ajoutée (ne sera pas utilisée pour la correspondance des modèles) à l'URL convertie qu'en cas de correspondance du chemin de demandes.
MapQuery modèle_demande nouvelle_demande [adresse_IP_serveur | nom_hôte]
Vous pouvez utiliser un astérisque (*) en tant que caractère générique dans le modèle. Le caractère tilde (~)placé juste après une barre oblique (/) doit être indiqué explicitement. Vous ne pouvez pas utiliser de caractère générique.
Vous pouvez spécifier une adresse IP (par exemple, 240.146.167.72) ou un nom d'hôte (par exemple, hostA.raleigh.ibm.com).
Ce paramètre est facultatif. Sans ce paramètre, le serveur utilise la directive pour toutes les demandes quel que soit le nom d'hôte de l'URL ou l'adresse IP d'où elles proviennent.
Il n'est pas possible d'indiquer de caractère générique pour une adresse IP de serveur.
En supposant que l'URL entrante se présente de la façon suivante :
/getsomthing?type=1
et que la règle MapQuery est la suivante :
MapQuery /getsomething?type=* /gettype/*
l'URL convertie sera /gettype/1 et sera utilisée dans le mappage de règles suivant.
Proxy /gettype/* http://server/gettype/*
L'URL convertie sera http://server/gettype/1.
Aucune
Cette directive permet de définir le nombre maximal d'unités d'exécution pouvant être actives simultanément. Si ce nombre maximal est atteint, le serveur conserve les nouvelles demandes jusqu'à la fin d'une autre demande et jusqu'à ce que des unités d'exécution soient disponibles. Généralement, plus votre machine est puissante, plus la valeur à utiliser pour cette directive doit être élevée. Si votre machine commence à passer trop de temps sur des tâches telles que la permutation de la mémoire, essayez de réduire cette valeur.
MaxActiveThreads
nombre_unités_exécution
MaxActiveThreads 100
Cette directive permet de définir la taille de la mémoire tampon pour les données dynamiques générées par le serveur. Les données dynamiques proviennent des programmes CGI, des instructions côté serveur et des programmes API.
La valeur peut être spécifiée en octets (O), kilooctets (K) ou en gigaoctets (G). Vous pouvez éventuellement insérer un caractère d'espacement entre le nombre et la valeur (O, K, M, G).
MaxContentLengthBuffer taille
MaxContentLengthBuffer 100 K
Cette directive permet de spécifier la taille maximale de chaque fichier journal. Chaque fichier journal ne pourra pas dépasser la taille définie par cette directive. Lorsqu'un fichier journal atteint la taille définie maximale, il est fermé et un nouveau fichier journal du même nom associé à l'incrément suivant est créé.
La valeur recommandée pour la définition de la directive MaxLogFileSize est entre 10 Mo au moins, mais sous 200 Mo. La taille du fichier journal réel est légèrement supérieure à celle que vous définissez. Définir une valeur trop basse affecte les performances du proxy car le serveur proxy ferme et ouvre plus fréquemment le fichier journal. Sur certaines plateformes, définir une valeur trop élevée entraîne une utilisation plus importante de la mémoire pour la mise en tampon des entrées-sorties. Lorsque la taille du fichier journal s'accroît, le proxy peut manquer de mémoire ou s'apparenter à une fuite de mémoire, même si les mémoires tampons E-S sont contrôlées par le système d'exploitation.
Vous pouvez spécifier la taille maximale dans l'une des unités suivantes : octets (B), kilooctets (K), mégaoctets (M) et gigaoctets (G).
MaxLogFileSize maximum {B | K | M | G}
MaxLogfileSize 128 M
Si la directive est mise en commentaire, il n'y a pas de limitation pour la taille du fichier journal.
Cette directive permet de spécifier le nombre maximal de demandes pouvant être reçues par le serveur au niveau d'une connexion permanente. Lorsque vous déterminez ce nombre, n'oubliez pas de prendre en compte le nombre d'images utilisées dans les pages. Pour chaque image, une demande séparée est nécessaire.
MaxPersistRequest nombre
MaxPersistRequest 5
Cette directive permet d'indiquer la profondeur maximale de la file d'attente de l'agent de cache des demandes d'extraction de pages en attente. Si vous disposez d'un système de taille importante disposant d'une grande quantité de mémoire, vous pouvez définir une file d'attente de grande taille pour les demandes d'extraction de pages sans pour autant manquer de mémoire.
La file d'attente des URL à mettre en mémoire cache est déterminée au début de chaque exécution d'agent de la mémoire cache. Si vous indiquez à l'agent de la mémoire cache de suivre les liens hypertexte vers les autres URL, ces autres URL ne seront pas comptées dans la file d'attente de la mémoire cache. Une fois que la valeur spécifiée dans la directive MaxURLs est atteinte, l'agent de la mémoire cache s'arrête même s'il reste des URL dans la file d'attente.
MaxQueueDepth
profondeur_maximum
MaxQueueDepth 250
Cette directive permet d'indiquer la durée maximale pendant laquelle l'agent de la mémoire cache extrait les URL lors d'une exécution particulière. La valeur 0 indique que l'exécution de l'agent de la mémoire cache n'est pas interrompue.
MaxRuntime {0 | durée_maximum}
MaxRuntime 2 heures 10 minutes
MaxRuntime 2 heures
Cette directive permet de définir le nombre maximal de sockets inactives ouvertes pour un serveur d'origine, quel qu'il soit. N'utilisez cette directive que si la valeur on est attribuée à la directive ServerConnPool.
MaxSocketPerServer numéro
MaxSocketPerServer 10
MaxSocketPerServer 5
Cette directive permet d'identifier le nombre maximal d'URL extraites par l'agent de la mémoire cache lors d'une exécution particulière. La valeur 0 signifie qu'il n'existe aucune limite. Lorsque vous utilisez le mode automatique de l'agent de la mémoire cache, les directives LoadURL et LoadTopCached sont prioritaires sur les directives MaxURLs.
MaxURLs nombre_maximum
MaxURLs 2000
Cette directive permet de spécifier les membres des groupes qui sont partagés par les serveurs utilisant l'accès distant à la mémoire cache.
Member nom {
sous-directive
sous-directive
.
.
}
Les sous-directives suivantes sont incluses :
Member douxamer.chocolat.ibm.com {
RCAAddr 127.0.0.1
RCAPort 6294
CacheSize 25G
Timeout 500 millisecondes
BindSpecific On
ReuseAddr Off
}
Aucune
Cette directive permet de définir le plug-in de l'application à exécuter à minuit pour l'archivage des journaux. La directive est initialisée lors de l'installation. Si vous ne spécifiez pas cette directive dans le fichier de configuration, l'archivage n'est pas effectué.
Midnight
/chemin/fichier:nom_fonction
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de l'étape de conversion de nom. Ce code fournit le mécanisme de conversion du chemin virtuel dans la demande en chemin physique sur le serveur, mappant les URl vers des objets spécifiques.
NameTrans modèle_demande /chemin/fichier:nom_fonction
[adresse_serveur_IP | nom_hôte]
Il n'est pas possible d'indiquer de caractère générique pour une adresse IP de serveur.
NameTrans /index.html /api/bin/icsextpgm.so:trans_url
Aucune
Sur les plateformes Linux et UNIX, cette directive permet d'empêcher le processus du serveur Caching Proxy de s'exécuter automatiquement en arrière-plan. La valeur par défaut de cette directive est off. Son format est :
NoBG [on | off]
NoBG on
NoBG off
Cette directive permet d'indiquer que le serveur ne doit pas mettre en mémoire cache les fichiers dont les URL correspondent au modèle donné. Vous pouvez utiliser plusieurs occurrences de cette directive dans le fichier de configuration. Incluez une directive séparée pour chaque modèle. Le modèle d'URL doit inclure le protocole.
Si ni CacheOnly ni NoCaching n'est défini, toute URL peut être mise en mémoire cache.
NoCaching modèle_URL
NoCaching http://joke/*
Aucune
Cette directive permet d'indiquer que vous ne voulez pas consigner les demandes d'accès effectuées à partir d'hôtes spécifiques ou de domaines correspondant à un modèle donné. Par exemple, vous pouvez ne pas vouloir consigner les demandes d'accès à partir des hôtes locaux.
Vous pouvez utiliser plusieurs occurrences de cette directive dans le fichier de configuration. Vous pouvez également placer plusieurs modèles au niveau de la même directive si vous les séparez par un ou plusieurs caractères d'espacement. Vous pouvez utiliser des noms d'hôte ou des adresses IP au niveau des modèles.
NoLog {nom_hôte | adresse_IP} [...]
NoLog 128.0.* *.edu localhost.*
Aucune
Si vous utilisez la directive http_proxy, ftp_proxy ou gopher_proxy pour l'enchaînement de proxys, vous pouvez faire appel à cette directive pour spécifier les domaines auxquels le serveur se connecte directement sans passer par un proxy.
Spécifiez la valeur en tant que chaîne de noms de domaines ou de modèles de nom de domaine. Séparez chaque entrée de la chaîne par une virgule. Ne placez pas de caractères d'espacement dans la chaîne.
Le mode d'entrée des modèles de cette directive est différent de celui des autres directives. Avant tout, vous ne pouvez pas utiliser le caractère générique (*). Vouspouvez spécifier un modèle en incluant uniquement la dernière partie d'un nom de domaine. Le serveur se connecte directement aux domaines se terminant par une chaîne correspondant aux modèles spécifiés. Cette directive s'applique uniquement au chaînage de proxys et est équivalente à une ligne @/= directe dans le fichier de configuration de SOCKS.
no_proxy
nom_domaine_ou_modèle[,...]
no_proxy www.someco.com,.raleigh.ibm.com,.some.host.org:8080
Dans cet exemple, le serveur ne passe pas par un proxy pour les demandes suivantes :
Aucune
Par défaut, lors de la réception d'une demande Range des navigateurs, Caching Proxy exige une réponse complète du serveur dorsal. Caching Proxy supprime l'en-tête Range de la demande, puis achemine cette dernière jusqu'au serveur dorsal. Une fois la réponse mise en cache sur le serveur proxy les demandes suivantes portant sur les mêmes ressources sont traitées sur le même serveur proxy, que les demandes soient des demandes Range ou non. En général, l'action par défaut de Caching Proxy améliore les performances et permet des temps de réponse plus courts pour les clients. Cependant, si la réponse ne peut pas être mise en mémoire cache, ou si elle est très volumineuse, l'action par défaut réduit les performances.
Utilisez la directive NoCacheOnRange, qui spécifie l'absence de mise en cache pour les demandes Range, pour résoudre l'incident décrit lors de l'utilisation de la configuration par défaut.
Lorsque vous activez la directive globalement dans le fichier ibmproxy.conf ou si vous l'activez comme option de la règle de mappage PROXY, Caching Proxy achemine l'en-tête de demande Range au serveur dorsal. Toutefois, Caching Proxy ne met pas en mémoire cache la réponse 206 (contenu partiel) du serveur dorsal.
L'activation de la directive NoCacheOnRange peut améliorer les performances du proxy dans les cas suivants :
NoCacheOnRange [on | off]
Vous pouvez également activer NoCacheOnRange dans une règle de mappage de proxy :
Proxy /not-cachable/* http://server.com/no-cachable-resources/* NoCacheOnRange
NoCacheOnRange off
Cette directive permet d'indiquer les en-têtes d'URL client à bloquer. Tout en-tête HTTP envoyé par un client peut être bloqué, y compris les en-têtes requis. Soyez très vigilant lorsque vous bloquez les en-têtes. Les en-têtes communs incluent :
Pour plus de détails, reportez-vous aux spécifications de protocole HTTP. Cette directive peut être spécifiée plusieurs fois.
NoProxyHeader en-tête
NoProxyHeader Referer:
Aucune
Cette directive permet de spécifier le nombre d'unités d'exécution utilisées par l'agent de la mémoire cache pour l'extraction des pages se trouvant dans la file d'attente. Définissez le nombre d'unités d'exécution en fonction de la vitesse du réseau interne et de votre connexion à Internet. La plage admise est comprise entre 1 et 100.
NumClients nombre
NumClients 4
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de l'étape de type d'objet. Ce code situe l'objet demandé dans le système de fichiers et spécifie son type MIME.
ObjectType modèle_demande /chemin/fichier:nom_fonction
ObjectType /index.html /api/bin/icsextpgm.so:obj_type
Aucune
Cette directive accélère le processus de mappage de règles pour les demandes entrantes lorsque le nombre de règles augmente.
Lorsque vous activez la directive OptimizeRuleMapping, au lieu de mapper les demandes d'URI entrantes par rapport à chaque règle une par une, le proxy mappe l'URI par rapport à un arbre de préfixes. L'arbre de préfixes aide le serveur proxy à supprimer la comparaison de chaînes redondantes dans les règles de mappage. Caching Proxy obtient alors de meilleures performances lorsque le nombre de règles de votre configuration dépasse 300.
OptimizeRuleMapping [on | off ]
OptimizeRuleMapping off
Cette directive permet de définir la durée maximale pendant laquelle le serveur peut envoyer des données à un client. La limite de temps s'applique aux demandes de fichiers locaux et aux demandes pour lesquelles le serveur se comporte comme un proxy. La limite de temps ne s'applique pas aux demandes qui commencent par un programme CGI.
Si le server n'envoie pas de réponse complète dans le laps de temps défini par cette directive, le serveur met fin à la connexion. Spécifiez la durée en combinant des heures, des minutes (ou mn) et des secondes (ou s).
OutputTimeout durée
OutputTimeout 30 minutes
Cette directive permet de spécifier le répertoire contenant les fichiers de configuration automatique du proxy générés à l'aide du formulaire de configuration de fichier PAC.
PacFilePath chemin_répertoire
Cette directive permet de spécifier un modèle pour les demandes à accepter et auxquelles vous voulez répondre avec un fichier provenant de votre serveur. Une fois qu'une demande correspond à un modèle d'une directive Pass, la demande n'est pas comparée aux modèles de demande des directives suivantes.
Pass modèle_demande [chemin_fichier [adresse_IP_serveur | nom_hôte]]
Vous pouvez utiliser un astérisque (*) en tant que caractère générique dans le modèle. Le caractère tilde (~)placé juste après une barre oblique (/) doit être indiqué explicitement. Vous ne pouvez pas utiliser de caractère générique.
Ce paramètre est facultatif. Si vous ne spécifiez aucun chemin, la demande elle-même est utilisée en tant que chemin.
Vous pouvez spécifier une adresse IP (par exemple, 240.146.167.72) ou un nom d'hôte (par exemple, hostA.raleigh.ibm.com).
Ce paramètre est facultatif. Sans ce paramètre, le serveur utilise la directive pour toutes les demandes quel que soit le nom d'hôte de l'URL ou l'adresse IP d'où elles proviennent.
Il n'est pas possible d'indiquer de caractère générique pour une adresse IP de serveur.
Pass /gooddoc/*
Pass /parts/* /customerA/catalog/* 240.146.167.72
Pass /parts/* /customerB/catalog/* 0.83.100.45
Pass /Admin/* /usr/lpp/internet/server_root/Admin/*
Pass /Docs/* /usr/lpp/internet/server_root/Docs/*
Pass /errorpages/* /usr/lpp/internet/server_root/pub/errorpages/*
Pass /* /usr/lpp/internet/server_root/pub/*
Pass /Admin/* /opt/ibm/edge/cp/racine_serveur/Admin/*
Pass /Docs/* /opt/ibm/edge/cp/racine_serveur/Docs/*
Pass /errorpages/* /opt/ibm/edge/cp/racine_serveur/pub/errorpages/*
Pass /* /opt/ibm/edge/cp/server_root/pub/*
Pass /Admin/* /usr/lpp/internet/server_root/Admin/*
Pass /Docs/* /usr/lpp/internet/server_root/Docs/*
Pass /errorpages/* /usr/lpp/internet/server_root/pub/errporpages/*
Pass /* /usr/lpp/internet/server_root/pub/*
Pass /Admin/* /opt/ibm/edge/cp/racine_serveur/Admin/*
Pass /Docs/* /opt/ibm/edge/cp/racine_serveur/Docs/*
Pass /errorpages/* /opt/ibm/edge/cp/racine_serveur/pub/errorpages/*
Pass /* /opt/ibm/edge/cp/racine_serveur/pub/*
Pass /icons/* C:\Program Files\IBM\edge\cachingproxy\cp\icons\*
Pass /Admin/* C:\Program Files\IBM\edge\cachingproxy\cp\Admin\*
Pass /Docs/* C:\Program Files\IBM\edge\cachingproxy\cp\Docs\*
Pass /erropages/* C:\Program Files\IBM\edge\cachingproxy\cp\pub\errorpages\*
Pass /* C:\Program Files\IBM\edge\cachingproxy\cp\pub\*
Cette directive permet de spécifier la durée pendant laquelle le serveur doit attendre entre les demandes client avant d'annuler une connexion permanente. La durée peut être exprimée selon tout incrément de durée valide, toutefois les secondes et les minutes sont les plus utilisées.
Le serveur utilise une directive de délai différente, InputTimeout, pour déterminer le temps d'attente pour l'envoi de la première demande du client une fois la connexion établie. Pour plus d'informations sur le délai d'entrée, voir InputTimeout — Spécifie le délai d'entrée.
Une fois que le serveur a envoyé la première réponse, il utilise la valeur définie pour PersistTimeout pour déterminer la longueur de l'attente de chaque demande suivante avant d'annuler la connexion permanente.
PersistTimeout durée
PersistTimeout 4 secondes
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur pour extraire des libellés PICS pour une URL spécifiée. La fonction peut soit créer dynamiquement un libellé PICS pour le fichier demandé, soit rechercher un libellé PICS dans une base de données ou un fichier de remplacement.
PICSDBLookup /chemin/fichier:nom_fonction
PICSDBLookup /api/bin/icsext05.so:get_pics
Aucune
Linux et UNIX uniquement. Utilisez cette directive pour spécifier l'emplacement du fichier qui contient l'ID processus de Caching Proxy. Lorsque le processus du serveur est lancé, il enregistre les ID processus (PID) dans un fichier. Si vous exécutez plusieurs instances du serveur sur un seul système, chaque instance doit posséder son propre fichier d'ID processus.
PidFile
chemin_vers_infos_fichier_PID
PidFile /usr/pidinfo
Sur les systèmes AIX, pour prendre en charge la carte IBM 4960 PCI Cryptographic Accelerator Card, des directives supplémentaires sont fournies.
Utilisez ces directives pour autoriser le proxy à charger le pilote de périphérique et ouvrir l'unité des jetons. Lors du chargement du pilote de périphérique, le serveur proxy utilise automatiquement le périphérique pour augmenter la vitesse de communication SSL.
Voir aussi SSLCryptoCard — Spécifie la carte de chiffrement installée.
PKCS11DefaultCert libellé_cert_défaut
Indiquez le label de certificat SSL par défaut stocké sur le jeton du périphérique.
PKCS11DriverPath chemin_absolu_au_pilote_de_carte
Indiquez le chemin d'accès absolu au pilote de périphérique pour la carte Cryptographic Accelerator Card.
PKCS11TokenPassword mot de passe
Indiquez le mot de passe pour ouvrir le périphérique de jeton.
PKCS11DefaultCert MyDefaultCertInTheToken
PKCS11DriverPath /usr/lib/pkcs11/PKCS11_API.so
PKCS11TokenPassword MyPasswordToOpenTheToken
Aucune
Les directives mentionnées ci-dessous ont été ajoutées au fichier ibmproxy.conf de Caching Proxy pour activer de nouvelles fonctions et extensions. Les formulaires de configuration et d'administration ne sont pas disponibles pour modifier la plupart de ces directives. Il faut utiliser un éditeur de texte standard, comme vi ou emacs, pour les modifier manuellement. Vous trouverez dans ce chapitre, par ordre alphabétique, d'autres informations relatives à chacune de ces nouvelles directives.
Dans le fichier ibmproxy.conf, il faut entrer les directives utilisées pour configurer l'extension du Caching Proxy, au format suivant :
<MODULEBEGIN> nom de l'extension
subdirective1
subdirective2
<MODULEEND>
Chaque programme d'extension analyse le fichier ibmproxy.conf et lit uniquement son propre bloc de sous-directives. L'analyseur de Caching Proxy ne tient pas compte de toutes les informations qui figurent entre <MODULEBEGIN> et <MODULEEND>.
Les plug-ins de Caching Proxy et certaines nouvelles fonctions requièrent l'ajout des directives API dans le fichier ibmproxy.conf. Dans la mesure où le serveur proxy interagit avec les plug-ins dans l'ordre dans lequel ils sont listés, soyez prudent lorsque vous décidez de l'ordre des directives dans le fichier de configuration du proxy. En effet, des directives données à titre de prototype (sous forme de commentaires) ont été ajoutées à la section API du fichier ibmproxy.conf. Ces directives API sont placées dans un ordre délibérément choisi. Lors de l'ajout de directives d'API pour permettre de nouvelles fonctionnalités et l'utilisation de plug-ins, respectez l'ordre dans lequel figurent les directives dans la section Prototypes du fichier de configuration. Vous pouvez également supprimer les marques de commentaires et modifier, si nécessaire, les directives API pour chacune des fonctionnalités ou chacun des plug-ins souhaités. Ajoutez les plug-ins générés par l'utilisateur après ceux qui sont fournis avec le produit.
Cette directive permet de spécifier le numéro du port sur lequel le serveur attend les demandes. Le numéro de port standard pour HTTP est 80. Les autres numéros de port inférieurs à 1024 sont réservés aux autres applications TCP/IP et ne doivent pas être utilisés. Les ports généralement utilisés pour les serveurs Web proxy sont les ports 8080 et 8008.
Lorsqu'un port différent de 80 est utilisé, les clients sont requis afin d'inclure un numéro de port spécifique pour les demandes destinées au serveur. Le numéro de port est précédé du caractère deux-points (:) et est placé après le nom d'hôte dans l'URL. Par exemple, à partir du navigateur, l'URL http://www.turfco.com:8008/ demande la page de bienvenue par défaut provenant d'un hôte nommé www.turfco.com à l'écoute du port 8008.
Vous pouvez utiliser l'option -p dans la commande ibmproxy pour remplacer ce paramètre lors du démarrage du serveur.
Port numéro
Si vous changez cette directive, vous devez arrêter le serveur puis le redémarrer pour que le changement soit effectif. La modification n'est pas prise en compte si vous redémarrez le serveur sans l'arrêter. (Voir Démarrage et arrêt de Caching Proxy.)
Port 80
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de l'étape PostAuth. Ce code sera exécuté quels que soient les codes retour provenant des étapes précédentes ou des gestionnaires PostAuth. Vous pouvez ainsi nettoyer les ressources attribuées pour traiter la demande.
PostAuth /chemin/fichier:nom_fonction
AuthExit /ics/api/bin/icsext05.so:post_exit
Aucune
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de l'étape PostExit. Ce code sera exécuté quels que soient les codes retour provenant des étapes précédentes ou des gestionnaires PostExit. Vous pouvez ainsi nettoyer les ressources attribuées pour traiter la demande.
PostExit /chemin/fichier:nom_fonction
PostExit /ics/api/bin/icsext05.so:post_exit
Aucune
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de l'étape PreExit. Ce code sera exécuté après la lecture d'une demande client et avant tout autre traitement. Vous pouvez appeler le module GoServe lors de cette étape.
PreExit /chemin/fichier:nom_fonction
PreExit /ics/api/bin/icsext05.so:pre_exit
Aucune
Cette directive permet d'activer les règles de configuration de protection pour les demandes correspondant à un modèle.
La configuration de protection est définie par les sous-directives de protection. Le format de la directive diffère selon que vous voulez désigner un libellé ou un fichier contenant les sous-directives de protection ou que vous voulez inclure les sous-directives de protection dans la directive Protect.
Ce paramètre peut prendre une des formes suivantes :
Protect modèle_demande [fichier_configuration | libellé[
[FOR adresse_IP_serveur | nom_hôte]
Protect modèle_demande [FOR adresse_IP_serveur | nom_hôte]
sous-directive valeur
sous-directive valeur
.
.
.
}
Les paramètres suivants sont utilisés :
Ce paramètre est facultatif. S'il est omis, la configuration de protection est définie par la protection DefProt la plus récente qui contient un modèle concordant.
Exemple :
Protect http://x.x.x.x PROT-ADMIN
A partir d'un navigateur Web :
Exemple :
Protect http://nomhote.exemple.com PROT-ADMIN
A partir d'un navigateur Web :
Vous pouvez spécifier une adresse IP (par exemple, FOR 240.146.167.72) ou un nom d'hôte (par exemple, FOR hostA.bcd.com).
Vous ne pouvez pas utiliser de caractères génériques pour spécifier les adresses IP.
Ce paramètre est facultatif. Sans ce paramètre, le serveur utilise la directive pour toutes les demandes quel que soit le nom d'hôte de l'URL ou l'adresse IP d'où elles proviennent.
Ces exemples utilisent les adresses IP. Si votre serveur reçoit des demandes commençant par /secret/ ou /topsecret/, il active une configuration de protection différente en fonction de l'adresse IP de la connexion réseau d'où provient la demande.
Protection BUS-PROT {
UserID busybody
GroupID webgroup
AuthType Basic
ServerID restricted
PasswdFile /docs/WWW/restrict.pwd
GroupFile /docs/WWW/restrict.grp
GetMask authors
PutMask authors
}
DefProt /secret/* /server/protect/setup1.acc
Protect /secret/scoop/*
Protect /secret/business/* BUS-PROT
Protect /topsecret/* {
AuthType Basic
ServerID restricted
PasswdFile /docs/WWW/restrict.pwd
GroupFile /docs/WWW/restrict.grp
GetMask topbrass
PutMask topbrass
}
Pass /secret/scoop/* /WWW/restricted/*
Pass /secret/business/* /WWW/confidential/*
Pass /topsecret/* /WWW/topsecret/*
Protect /secret/* CustomerA-PROT FOR 0.67.106.79
Protect /secret/* CustomerB-PROT FOR 0.83.100.45
Protect /topsecret/* 0.67.106.79 {
AuthType Basic
ServerID restricted
PasswdFile /docs/WWW/customer-A.pwd
GroupFile /docs/WWW/customer-A.grp
GetMask A-brass
PutMask A-brass
}
Protect /topsecret/* 0.83.100.45 {
AuthType Basic
ServerID restricted
PasswdFile /docs/WWW/customer-B.pwd
GroupFile /docs/WWW/customer-B.grp
GetMask B-brass
PutMask B-brass
}
Protect http://host1/* proxy-prot
Protect /secret/* CustomerA-PROT FOR hôteA.bcd.com
Protect /secret/* CustomerB-PROT FOR hôteB.bcd.com
Protect /topsecret/* hostA.bcd.com {
AuthType Basic
ServerID restricted
PasswdFile /docs/WWW/customer-A.pwd
GroupFile /docs/WWW/customer-A.grp
GetMask A-brass
PutMask A-brass
}
Protect /topsecret/* hostB.bcd.com {
AuthType Basic
ServerID restricted
PasswdFile /docs/WWW/customer-B.pwd
GroupFile /docs/WWW/customer-B.grp
GetMask B-brass
PutMask B-brass
}
Par défaut, la protection est fournie pour les formulaires de configuration et d'administration par une directive Protect avec un modèle de demande /admin-bin/*.
Cette directive permet de définir une configuration de protection dans le fichier de configuration. Vous donnez à la configuration de protection un nom et définissez le type de la protection à l'aide des sous-directives de protection.
Protection nom_libellé {
sous-directive valeur
sous-directive valeur
.
.
.
}
Pour obtenir des descriptions détaillées des sous-directives de protection, voir Sous-directives de protection — Spécifie le mode de protection d'un ensemble de ressources.
Protection NAME-ME {
AuthType Basic
ServerID restricted
PasswdFile /WWW/password.pwd
GroupFile /WWW/group.grp
GetMask groupname
PutMask groupname
}
Protect /admin-bin/* {
ServerId Private_Authorization
AuthType Basic
GetMask All@(*)
PutMask All@(*)
PostMask All@(*)
Mask All@(*)
PasswdFile /opt/ibm/edge/cp/server_root/protect/webadmin.passwd
}
Ci-dessous se trouvent des descriptions de chaque sous-directive de protection pouvant être utilisées dans une configuration de protection. Les sous-directives sont classées par ordre alphabétique.
Les configurations de protection peuvent se trouver soit dans des fichiers séparés soit dans les fichiers de configurations comme parties des directives DefProt, Protect ou Protection.
Cette sous-directive de protection permet de limiter l'accès en fonction des noms utilisateur et des mots de passe. Spécifiez le type d'authentification à utiliser lorsque le client envoie un mot de passe au serveur. Avec l'authentification de base (AuthType Basic), les mots de passe sont envoyés au serveur sous la forme de texte. Ils sont codés, mais non chiffrés.
AuthType Basic
Cette sous-directive de protection permet de spécifier des modèles de noms d'utilisateur, de groupes, d'adresses admis pour effectuer des demandes DELETE au niveau d'un répertoire protégé.
DeleteMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Cette sous-directive de protection permet de spécifier des modèles de noms utilisateur, de groupes, d'adresses admis pour effectuer des demandes GET au niveau d'un répertoire protégé.
GetMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
GetMask All@(*)
Cette sous-directive Protection permet de spécifier le nom et le chemin du fichier du groupe de serveurs devant être utilisé par la configuration de protection. Les groupes définis dans ce fichier de groupes de serveurs peuvent ensuite être utilisés par :
GroupFile /docs/etc/WWW/restrict.group
Cette sous-directive permet de spécifier des modèles de noms d'utilisateur, de groupes et d'adresses admis pour effectuer des demandes HTTP non prises en charge par d'autres sous-directives de masque.
Mask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
MASK WEBADM,webadm
Cette sous-directive de protection permet de limiter l'accès en fonction des noms utilisateur et des mots de passe. Spécifiez le nom et le chemin du fichier de mots de passe devant être utilisé par cette configuration de protection.
Etant donné que certains navigateurs mettent en mémoire cache les ID utilisateur et les mots de passe par domaine de sécurité (ID utilisateur) dans l'hôte, suivez les instructions ci-dessous lors de la spécification des ID serveur et des fichiers de mots de passe :
PasswdFile /docs/etc/WWW/restrict.password
PasswdFile "c:\test this\admin.pwd"
Pour un serveur sécurisé, cette sous-directive de protection permet de spécifier des modèles d'utilisateurs, de groupes et d'adresses admis pour effectuer des demandes POST au niveau d'un répertoire protégé.
PostMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Cette sous-directive de protection permet de spécifier des modèles d'utilisateurs, de groupes, d'adresses admis pour effectuer des demandes PUT au niveau d'un répertoire protégé.
PutMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Cette sous-directive de protection permet de limiter l'accès en fonction des noms utilisateur et des mots de passe. Spécifiez un nom à associer au fichier de mots de passe en cours d'utilisation. Il n'est pas nécessaire que le nom soit un nom de machine réel.
Le nom est utilisé comme identificateur de l'élément à l'origine de la demande. Etant donné que plusieurs configurations de protection peuvent utiliser différents fichiers de mots de passe, l'association d'un nom à une protection de configuration peut aider le client lors du choix du mot de passe à envoyer. La plupart des clients affichent ce nom lorsqu'ils sont invités à entrer un nom utilisateur et un mot de passe.
Etant donné que certains navigateurs mettent en mémoire cache les ID utilisateur et les mots de passe par domaine de sécurité (ID utilisateur) dans l'hôte, suivez les instructions ci-après lors de la spécification des ID serveur et des fichiers de mots de passe :
ServerID restricted
Cette directive permet d'indiquer les protocoles que Caching Proxy doit traiter et mapper une requête à un serveur. Les protocoles valides sont http, ftp et gopher.
La directive du proxy transmet la requête à un serveur éloigné. Par exemple, avec, la directive suivante, toutes les demandes seront transmises à l'URL désignée :
Proxy /* http://nom.serveur.proxy/*
Pour un serveur proxy inversé sécurisé, utilisez la directive suivante :
Proxy /* https://nom.serveur.proxy/*
Si vous voulez que les restrictions relatives à votre serveur proxy soient moindres, supprimez les commentaires des directives ci-dessous dans votre fichier de configuration. Ces directives peuvent cependant introduire un problème de sécurité lorsque le proxy est configuré comme proxy inversé.
Proxy http:*
Proxy ftp:*
Proxy gopher:*
Paramètres facultatifs :
S'applique aux configurations avec proxy inversé uniquement.
Cette option demande à Caching Proxy de conserver un mappage un à un entre le socket côté client et le socket sortant. Cette option est utile pour certaines applications, comme l'authentification basée sur connexion, qui exige que le proxy conserve le socket côté client actif et qu'il réutilise le socket pour les demandes provenant du même socket côté client.
En cas de correspondance avec la règle du proxy, cette option demande au proxy de ne pas mettre en cache les réponses correspondantes.
En cas de correspondance avec la règle du proxy et de présence d'en-tête Range dans la demande, cette option demande au proxy de ne pas mettre en cache la réponse correspondante. Pour plus d'informations, voir NoCacheOnRange — Indique la non mise en cache pour les demandes Range.
S'applique aux configurations avec proxy inversé uniquement.
Utilisez cette option si le plug-in de réécriture de la jonction est activé. Cette option ne permet pas au proxy de réécrire les réponses correspondantes en cas de correspondance de l'URL entrante. Pour plus d'informations, voir Activation de la réécriture de jonction (facultatif) et Définition de la jonction avec l'option JunctionPrefix (méthode recommandée).
S'applique aux configurations avec proxy inversé uniquement.
Utilisez cette option si le plug-in de réécriture de la jonction est activé. Vous pouvez déclarer le préfixe de jonction dans la règle Proxy en utilisant le format ci-dessous au lieu de déduire le préfixe de jonction en fonction du premier modèle d'URL. Pour plus d'informations, voir Activation de la réécriture de jonction (facultatif) et Définition de la jonction avec l'option JunctionPrefix (méthode recommandée).
Proxy modèle_demande chemin_serveur_cible [[ip]:port]
[UseSession | NoCaching | NoCacheOnRange | NoJunction | JunctionPrefix:/préfixe_url]
Voici un exemple d'option UseSession pour la directive Proxy :
Proxy /abc/* http://server1/default/abc/* :80 UseSession
Lorsque la requête client entrante provient du port 80 et que l'URL associée correspond au modèle /abc/*, l'URL est mappée à http://server1/default/abc/*.
Aucune.
Cette directive permet de spécifier le chemin et le nom du fichier dans lequel le serveur doit consigner les statistiques d'accès au serveur proxy. Par défaut, le serveur inscrit une entrée dans ce fichier journal dès qu'il se comporte en tant que proxy pour une demande client. Vous pouvez utiliser la directive NoLog si vous ne voulez pas consigner de demandes provenant de certains clients.
Le serveur démarre un nouveau fichier journal chaque jour à minuit s'il est en cours d'exécution. Sinon, le serveur démarre un nouveau fichier journal dès que vous le démarrez. Lors de la création du fichier, le serveur utilise le nom du fichier spécifié et ajoute un suffixe de date ou une extension. Le suffixe de date ou l'extension apparaît au format Mmmjjaaaa, où Mmm correspond aux trois premières lettres du mois, jj au jour du mois et aaaa à l'année.
Nous vous recommandons de supprimer les anciens fichiers journaux car ils peuvent occuper un espace disque important sur votre disque dur.
ProxyAccessLog
chemin/fichier
Cette directive permet de spécifier une application personnalisée devant être appelée par le serveur lors de la phase Proxy Advisor. Ce code doit servir la demande.
ProxyAdvisor /chemin/fichier:nom_fonction
ProxyAdvisor /api/bin/customadvise.so:proxyadv
Aucune
La directive ProxyForwardLabels permet d'effectuer un filtrage PICS au niveau du serveur proxy, du client ou au niveau de deux proxys de la hiérarchie de proxys.
Si ProxyForwardLabels a la valeur On, le serveur proxy génère des en-têtes HTTP PICS-Label: pour tous les libellés PICS trouvés, y compris les libellés provenant du serveur d'origine, des bureaux de libellés, de la mémoire cache des libellés de Caching Proxy et des plug-ins du fournisseur de libellés.
Si ProxyForwardLabels a la valeur Off, les en-têtes HTTP PICS-Label: ne sont pas générés.
ProxyForwardLabels {on | off}
ProxyForwardLabels Off
Cette directive permet de générer un en-tête "From:". Elle est généralement utilisé pour donner une adresse électronique de l'administrateur proxy.
ProxyFrom
adresse_électronique
Le paramètre ProxyFrom webmaster@proxy.ibm.com provoque les modifications d'en-tête suivantes :
En-tête d'origine | En-tête modifié |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com/ |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
Pragma: no-cache | From: webmaster@proxy.ibm.com |
Pragma: no-cache |
Aucune
Cette directive permet d'indiquer comment le serveur doit réagir lorsque l'utilisateur clique sur le bouton Recharger dans le navigateur. Si la valeur On est attribuée à ProxyIgnoreNoCache, lors des périodes de chargement important, le serveur ne demande pas la page à partir du serveur de destination et fournit la copie mise en mémoire cache du file si cette dernière est disponible. Le serveur ignore l'en-tête Pragma: no-cache envoyé par le navigateur.
ProxyIgnoreNoCache {on | off}
ProxyIgnoreNoCache off
Cette directive indique si une connexion permanente est conservée avec le client. Une connexion permanente réduit le temps d'attente pour les utilisateurs et réduit la charge de l'unité centrale sur le serveur proxy, mais nécessite plus de ressources. Pour une connexion permanente, des unités d'exécution supplémentaires sont requises sur le serveur et donc plus de mémoire.
Les connexions permanentes ne doivent pas être utilisées dans une configuration de serveur proxy à plusieurs niveaux si l'un des proxy n'est pas compatible HTTP 1.1.
ProxyPersistence {on | off}
ProxyPersistence on
Cette directive permet d'indiquer si le proxy transmet l'adresse IP du client au serveur de destination.
ProxySendClientAddress {IP_Client: | OFF}
La directive ProxySendClientAddress IP_Client: provoque les modifications d'en-tête suivantes :
En-tête d'origine | En-tête modifié |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
Pragma: no-cache | IP_Client: 0.67.199.5 |
Pragma: no-cache |
Aucune
Cette directive permet de spécifier une chaîne Agent utilisateur remplaçant la chaîne envoyée par le client. Ainsi, vous renforcez le caractère anonyme lors de la visite de sites Web. Cependant, certains sites possèdent des pages personnalisées dépendant de la chaîne Agent utilisateur. Le recours à la directive ProxyUserAgent empêche l'affichage de ces pages personnalisées.
ProxyUserAgent
nom_produit/version
La directive ProxyUserAgent Caching Proxy/8.5 provoque les modifications d'en-tête suivantes :
En-tête d'origine | En-tête modifié |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
Agent utilisateur : Mozilla/ 2.02 OS2 | Agent utilisateur : Caching Proxy/8.5 |
Pragma: no-cache | Pragma: no-cache |
Aucune
Cette directive permet de gérer le format de l'en-tête HTTP. Elle admet quatre valeurs. Si ProxyVia prend la valeur Full, Caching Proxy ajoute un en-tête Via dans la demande ou la réponse. Si un en-tête Via est déjà dans le flux, Caching Proxy ajoute les informations sur l'hôte à la fin. Si elle prend la valeur Set, Caching Proxy attribue les informations sur l'hôte à l'en-tête Via ; si un en-tête Via se trouve déjà dans le flux, Caching Proxy le supprime. Si la directive prend la valeur Pass, Caching Proxy transmet toutes les informations de l'en-tête telles quelles. Si elle prend la valeur Block, Caching Proxy ne transmet aucun en-tête Via.
ProxyVia {Full | Set | Pass | Block}
ProxyVia Pass
ProxyVia Full
S'applique aux configurations avec proxy inversé uniquement.
La directive de mappage ProxyWAS fonctionne de la même façon que la directive Proxy mais indique aussi à Caching Proxy que les demandes correspondantes sont dirigées vers un serveur WebSphere Application Server. Pour afficher des exemples d'utilisation de cette directive, voir Proxy — Identifie les protocoles de proxy ou le proxy inversé.
ProxyWAS modèle_demande chemin_serveur_cible [[ip]:port]
[UseSession | NoCaching | NoCacheOnRange | NoJunction | JunctionPrefix:/préfixe_url]
Aucune
Cette directive permet de spécifier si le serveur se comporte comme un proxy ou comme un serveur proxy et de contenu. Nous vous recommandons d'utiliser Caching Proxy en tant que proxy uniquement.
PureProxy {on | off}
PureProxy on
Cette directive permet de spécifier l'âge limite d'un journal, en jours, avant qu'il ne soit purgé. Si PurgeAge a la valeur 0, le fichier journal n'est jamais supprimé.
PurgeAge nombre
PurgeAge 7
Cette directive d'indiquer la taille (en mégaoctets) pouvant être atteinte par les fichiers journaux d'archivage avant que ces derniers ne soient purgés. Si PurgeSize a la valeur 0, il n'y a pas de taille limite et les fichiers ne sont jamais supprimés.
Le paramètre défini pour PurgeSize s'applique à tous les journaux d'un type donné. Par exemple, si vous consignez les erreurs (une entrée Errorlog est présente dans le fichier de configuration) et si la valeur 10 Mo est attribuée à PurgeSize, Caching Proxy calcule la taille de tous les journaux d'erreur, additionne ces tailles, puis supprime les journaux jusqu'à ce que la taille totale soit inférieure à 10 Mo.
PurgeSize nombre_de_Mo
PurgeSize 0
Cette directive permet de spécifier le nom et l'emplacement du fichier de configuration RCA (Remote Cache Access).
RCAConfigFile /etc/nom_fichier
RCAConfigFile /etc/user2rca.conf
RCAConfigFile /etc/rca.conf
Cette directive permet de spécifier le nombre d'unités d'exécution en cours sur un port RCA.
RCAThreads nombre_unités_exécution
RCAThreads 50
MaxActiveThreads x [(ArraySize -1) / (2 x ArraySize -1)]
Cette directive permet de spécifier la durée maximale admise sans activité réseau avant l'annulation de la connexion.
ReadTimeout durée
ReadTimeout 5 minutes
Cette directive permet de spécifier un modèle pour les demandes à accepter et à envoyer à d'autres serveurs. Lorsqu'une demande correspond à un modèle de directive Redirect, celle-ci n'est pas comparée aux modèles des autres directives du fichier de configuration.
Redirect modèle_demande URL [adresse_IP_serveur | nom_hôte]
Vous pouvez utiliser un astérisque (*) en tant que caractère générique dans le modèle. Le caractère tilde (~)placé juste après une barre oblique (/) doit être indiqué explicitement. Vous ne pouvez pas utiliser de caractère générique.
URL doit contenir une spécification de protocole et le nom du serveur auquel envoyer la demande. Il peut également contenir un chemin ou un nom de fichier. Si modèle-demande utilise un caractère générique, un caractère générique peut également être utilisé pour le chemin ou le nom de fichier au niveau de l'URL. La partie de la demande d'origine qui correspond au caractère générique de l'élément modèle_demande est insérée à la place du caractère générique de l'URL.
Vous pouvez spécifier une adresse IP (par exemple, 240.146.167.72) ou un nom d'hôte (par exemple, hostA.bcd.com).
Ce paramètre est facultatif. Sans ce paramètre, le serveur utilise la directive pour toutes les demandes quel que soit le nom d'hôte de l'URL ou l'adresse IP d'où elles proviennent.
Il n'est pas possible d'indiquer de caractère générique pour une adresse IP de serveur.
Redirect /chef/truc/* http://www.autre.org/wahoo/*
Redirect /stuff/* http://www.chief.org/wahoo/* 240.146.167.72 redirectcode: 302
Redirect /stuff/* http://www.dawg.com/pound/* 0.83.100.45 redirectcode: 302
Redirect /truc/* http://www.chef.org/wahoo/* hôteA.bcd.com
Redirect /truc/* http://www.dawg.com/pound/* hôteB.bcd.com
Aucune
Cette directive autorise Caching Proxy à mettre en cache plusieurs variantes d'une ressource (URI) sur la base de l'en-tête Cookie.
Pour plus d'informations, voir SupportVaryHeader — Met en cache plusieurs variantes d'une ressource sur la base de l'en-tête HTTP Vary.
RegisterCacheIdTransformer Cookie nom-cookie
La variable nom-cookie correspond au nom indiqué dans l'en-tête Cookie de la demande client.
RegisterCacheIdTransformer Cookie Usergroup
Pour obtenir un exemple d'utilisation de cette directive en association avec SupportVaryHeader, voir SupportVaryHeader — Met en cache plusieurs variantes d'une ressource sur la base de l'en-tête HTTP Vary.
Aucune
S'applique aux configurations avec proxy inversé uniquement.
La directive de mappage ReversePass examine le flux du serveur pour détecter les demandes qui sont réécrites suite à un réacheminement automatique. En général, lorsqu'un serveur renvoie un code HTTP de la classe 3xx (par exemple, 301, moved permanently, ou 303, see other), le serveur envoie un message contenant la réponse, qui indique au client demandeur de diriger ses demandes futures vers l'URL ou l'adresse IP adéquate. Dans le cas d'une configuration de proxy inversé, un message de réacheminement issu du serveur d'origine peut amener les navigateurs clients à contourner le serveur proxy pour les demandes suivantes. Pour éviter que les clients ne contactent directement le serveur d'origine, utilisez la directive ReversePass pour intercepter les demandes destinées spécialement au serveur d'origine.
A la différence d'autres directives de mappage qui traitent le flux de demandes, ReversePass compare son modèle au flux de réponses. Le flux de réponses désigne la réponse que le serveur proxy reçoit du serveur origine et qu'il transmet au client.
ReversePass URL_modifiée URL_proxy [hôte:port]
L'option hôte:port permet au proxy d'appliquer une règle ReversePass différente en fonction du nom d'hôte et du port du serveur dorsal.
ReversePass http://backend.company.com:9080/* http://edge.company.com/*
Le port 9080 est le port par défaut de
Application Service at the Edge. Ce type de demande peut être généré si le serveur
d'applications d'origine a renvoyé un code 3xx au client.ReversePass http://edge.company.com:9080/*
http://edge.company.com/*
Aucune
S'applique aux configurations avec proxy inversé uniquement.
Cette directive permet d'indiquer le modèle de domaine à remplacer. La directive remplace le domaine modèle1_domaine par modèle2_domaine.
RewriteSetCookieDomain modèle1_domaine modèle2_domaine
RewriteSetCookieDomain .internal.com .external.com
Aucune
S'applique aux configurations avec proxy inversé uniquement.
Cette directive permet d'activer ou de désactiver le réacheminement RTSP. les valeurs admises sont on ou off.
RTSPEnable {on | off}
RTSPEnable on
Aucune
S'applique aux configurations avec proxy inversé uniquement.
Cette directive permet d'indiquer les serveurs proxy RTSP devant recevoir les requêtes réacheminées. Plusieurs serveurs peuvent être indiqués pour différents types de flux de données. Le format de la directive est :
rtsp_proxy_server adresse dns serveur[:port] rang par défaut [liste de types mime]
rtsp_proxy_server rproxy.mycompany.com:554 1
rtsp_proxy_server fw1.mycompany.com:554 2
rtsp_proxy_server fw1.mycompany.com:555 3
rtsp_proxy_server fw2.mycompany.com:557 4
Aucune
S'applique aux configurations avec proxy inversé uniquement.
Cette directive indique le nombre de requêtes devant être reçues avant qu'une requête RTSP soit réacheminée vers un serveur proxy plutôt que vers un serveur d'origine. Les serveurs proxy RealNetworks stockent en mémoire cache les flux de données dès la première demande ; cette méthode de mise en mémoire cache double la largeur de bande utilisée pour la réception d'un flux de données. La définition d'une valeur de seuil supérieure à 1 empêche la mise en mémoire cache des requêtes émises une seule fois. Le format de la directive est :
rtsp_proxy_threshold nombre d'occurrences
rtsp_proxy_threshold 5
Aucune
S'applique aux configurations avec proxy inversé uniquement.
Cette directive indique le nombre d'URL uniques conservées en mémoire en vue d'un réacheminement. Le proxy consulte cette liste pour déterminer si une URL donnée a déjà été rencontrée. Quand la liste est plus longue, le serveur proxy est mieux à même d'envoyer au même proxy une demande identique à celle qu'il a déjà reçue ; il faut toutefois savoir que chaque entrée de liste consomme environ 16 octets de mémoire.
rtsp_url_list_size taille de la liste
rtsp_url_list_size 8192
Aucune
Par défaut, lorsque Caching Proxy mappe des demandes par rapport à des règles définies dans le fichier ibmproxy.conf, le processus de correspondance fait la distinction entre les majuscules et les minuscules. Toutefois, certaines URL d'application ne font pas la distinction entre les majuscules et les minuscules. Pour gérer correctement ces demandes, la directive RuleCaseSense est fournie. Lorsque la directive est définie sur off, le proxy fait correspondre des demandes sans distinction des majuscules/minuscules.
RuleCaseSense {on | off}
RuleCaseSense on
Cette directive permet de définir le temps alloué pour l'exécution d'un programme CGI démarré par le serveur. Lorsque le délai d'expiration est dépassé, le serveur met fin au programme. Sous Linux et UNIX, cette opération est effectuée par le signal KILL.
Entrez la durée en combinant des heures, des minutes (mn) ou des secondes (s).
ScriptTimeout délai
ScriptTimeout 5 minutes
Cette directive permet de spécifier que les demandes envoyées à partir de Caching Proxy vers un serveur aval doivent utiliser le protocole HTTP version 1.0. (Un serveur en aval est un autre serveur proxy dans une chaîne de proxys ou un serveur d'origine qui va traiter la demande.)
Si cette directive est utilisée, Caching Proxy spécifie HTTP 1.0 comme protocole dans la ligne de la demande. Seules les fonctionnalités propres à HTTP 1.0 et certaines fonctions HTTP 1.1, telles que les en-têtes cache-control pris en charge par la plupart des serveurs HTTP 1.0, seront envoyées au serveur en aval. Cette directive doit être utilisée si un serveur aval ne traite pas correctement les demandes HTTP 1.1.
Si la directive SendHTTP10Outbound n'est pas spécifiée, Caching Proxy spécifie HTTP 1.1 comme protocole dans la ligne de la demande. Les fonctionnalités de HTTP 1.1 telles que les connexions permanentes peuvent également être utilisées dans la demande.
SendHTTP10Outbound modèle_url
Cette directive peut être spécifiée plusieurs fois, par exemple :
SendHTTP10Outbound http://www.hôtea.com/*
SendHTTP10Outbound http://www.hôteb.com/*
Pour assurer la compatibilité amont, la syntaxe précédente de SendHTTP10Outbound est traitée comme suit :
Aucune
S'applique aux configurations avec proxy inversé uniquement.
Lorsqu'il fonctionne en proxy inversé, Caching Proxy reçoit les demandes HTTP d'un client et envoie les demandes vers le serveur d'origine. Par défaut, Caching Proxy écrit le nom d'hôte du serveur d'origine dans l'en-tête HOST de la demande qu'il envoie au serveur d'origine. Si la directive SendRevProxyName a la valeur yes, Caching Proxy écrit son propre nom d'hôte dans l'en-tête HOST. Cette directive permet d'apporter une configuration spéciale au serveurs dorsaux, car la demande adressée au serveur d'origine semble toujours provenir du serveur proxy, même si elle est réacheminée d'un serveur dorsal à un autre.
Cette directive diffère de la directive de mappage ReversePass comme suit : La directive ReversePass intercepte les demandes avec une syntaxe définie et remplace différents contenus de demandes que vous spécifiez. La directive SendRevProxyName peut être définie uniquement pour remplacer le nom d'hôte de Caching Proxy par le nom d'hôte du serveur d'origine. Cette directive n'est pas utile pour la configuration de Application Service at the Edge.
SendRevProxyName {yes | no}
Cette directive définit la fréquence à laquelle l'unité d'exécution du processus de récupération de place vérifie les connexions du serveur ayant expiré (définie avec la directive ServerConnTimeout). N'utilisez cette directive que si la valeur on est attribuée à la directive ServerConnPool.
ServerConnGCRun intervalle de temps
ServerConnGCRun 2 minutes
ServerConnGCRun 2 minutes
Cette directive permet au proxy de regrouper ses connexions sortantes vers les serveurs d'origine. L'activation de cette directive (en l'associant à on) accroît les performances et tire davantage parti des serveurs d'origine permettant des connexions permanentes. Vous pouvez également spécifier la durée du maintien d'une connexion inutilisée à l'aide de la directive ServerConnTimeout.
ServerConnPool {on | off}
ServerConnPool off
Cette directive permet de limiter la durée admise pour les activités réseau avant l'annulation de la connexion. N'utilisez cette directive que si la valeur on est attribuée à la directive ServerConnPool.
ServerConnTimeout time-spec
ServerConnTimeout 30 seconds
ServerConnTimeout 10 seconds
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de ses routines d'initialisation. Ce code est exécuté avant la lecture des demandes client et à chaque redémarrage du serveur.
Si vous utilisez les modules GoServe au cours des étapes PreExit ou Service, vous devez appeler le module gosclone.
ServerInit /chemin/fichier:nom_fonction [chaîne_initialisation]
ServerInit /ics/api/bin/icsext05.so:svr_init
Aucune
Cette directive permet de spécifier le répertoire dans lequel est installé le programme du serveur (répertoire de travail en cours du serveur). Les directives de consignation utilisent ce répertoire en tant que répertoire principal par défaut lorsque des chemins relatifs sont spécifiés.
Sous Windows, le répertoire est précisé au cours de l'installation.
ServerRoot
chemin_répertoire
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de l'étape d'arrêt. Ce code est exécuté lors d'un arrêt ou d'un redémarrage du serveur. Il permet de libérer des ressources allouées par une fonction d'application PreExit.
ServerTerm /chemin/fichier:nom_fonction
ServerTerm /ics/api/bin/icsext05.so:shut_down
Aucune
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de l'étape Service. Ce code doit gérer la demande du client. Par exemple, il envoie le fichier ou exécute le programme CGI.
Il n'existe pas de paramètre par défaut pour cette directive. Si la demande correspond à une règle Service (fonction d'application indiquée dans une directive Service), mais que la fonction renvoie HTTP_NOACTION, le serveur génère une erreur et la demande échoue.
Service modèle_demande/chemin/fichier:nom_fonction
[adresse_IP_serveur |
nom_hôte]
Il n'est pas possible d'indiquer de caractère générique pour une adresse IP de serveur.
Service /index.html /ics/api/bin/icsext05.so:serve_req
Service /cgi-bin/hexcalc* /ics/api/calculator:HEXcalc*
Aucune
Utilisez cette directive pour indiquer un code d'arrêt pour les demandes d'URL. En cas d'utilisation du code d'arrêt dans une demande, Caching Proxy ne tient compte que des caractères précédant le code d'arrêt lors du traitement de la demande et détermine si le fichier demandé est ou non placé en mémoire cache. Lorsque plusieurs codes d'arrêt sont utilisés, Caching Proxy compare les URL entrantes aux codes d'arrêt dans l'ordre dans lequel elles sont définies dans le fichier ibmproxy.conf.
SignificantURLTerminator chaîne_d'arrêt en cours
SignificantURLTerminator &.
Dans cet exemple, les deux demandes suivantes sont considérées comme identiques.
http://www.exampleURL.com/tx.asp?id=0200&.;x=004;y=001
http://www.exampleURL.com/tx.asp?id=0200&.;x=127;y=034
Aucune
Cette directive permet de configurer le serveur SMTP qu'utilise la routine interne sendmail dans le cadre de Caching Proxy pour Windows. Cette routine nécessite également la définition des directives WebMasterEMail — Définit une adresse électronique pour la réception des rapports d'un serveur sélectionné et WebMasterSocksServer (Windows uniquement)— Configure un serveur socks pour la routine sendmail.
SMTPServer adresse IP ou nom d'hôte du serveur SMTP
SMTPServer mybox.com
Aucune
Cette directive permet d'activer ou de désactiver la prise en charge de SNMP.
SNMP {on | off}
SNMP off
Cette directive permet de définir le mot de passe entre le sous-agent DPI et l'agent SNMP de Webserver. Le nom de communauté SNMP autorise un utilisateur à visualiser les variables de performances contrôlées par SNMP pour une communauté de serveurs. L'administrateur système définit les variables à l'aide desquelles les serveurs peuvent être visualisés une fois le mot de passe entré. Si vous modifiez le nom de communauté SNMP, modifiez-le également dans le fichier /etc/snmpd.conf.
SNMPCommunity nom
SNMPCommunity public
Cette directive permet de mettre des données en mémoire cache lors d'une demande sécurisée dans le cadre de l'utilisation d'un proxy inversé. Elle configure la mise en mémoire pour toutes les connexions au serveur proxy, qu'il s'agisse de connexions client ou de connexions au serveur de contenu dorsal.
SSLCaching {on | off}
SSLCaching off
Utilisez cette directive pour préciser les libellés des clés qui permettent au proxy de déterminer le certificat à envoyer au client lorsque Caching Proxy fonctionne comme un proxy inversé pour les domaines multiples qui proposent leurs propres certificats SSL et pour indiquer au serveur proxy s'il doit ou non récupérer un certificat PKI du client en vue d'authentifier le client.
Avec la directive SSLCertificate, Caching Proxy peut effectuer la distinction entre un certificat émis par une autorité de certification ou un certificat d'auto-signature. Toutefois, si vous acceptez tout certificat émis par une autorité de certification (option ClientAuthRequired), l'utilisation de cette directive peut permettre à des utilisateurs non autorisés d'accéder au serveur proxy. Lorsque vous utilisez l'option ClientAuthRequired sur la directive SSLCertificate, vous pouvez utiliser l'option d'expression logique pour déterminer quels utilisateurs autorisés peuvent accéder au canal SSL.
Lorsqu'une expression logique supplémentaire est ajoutée dans la directiveSSLCertificate, Caching Proxy extrait des valeurs du certificat client et calcule l'expression logique. Si l'expression est satisfaite par les valeurs du certificat client, Caching Proxy accorde au client l'utilisation de la connexion SSL ; sinon, la connexion est arrêtée et fermée.
SSLCertificate serveurIP/nomhôte LibelléCertificat
[NoClientAuth | ClientAuthRequired logic-expression]
L'option d'expression logique est valide uniquement si elle est utilisée avec l'option ClientAuthRequired. Lorsqu'une expression logique supplémentaire est ajoutée dans la directiveSSLCertificate, Caching Proxy extrait des valeurs du certificat client et calcule l'expression logique. Si l'expression est satisfaite par les valeurs du certificat client, Caching Proxy accorde au client l'utilisation de la connexion SSL ; sinon, la connexion est arrêtée et fermée.
SSLCertificate www.abc.com ABCCert
SSLCertificate 204.146.167.72 intABCCert
SSLCertificate www.xyz.com XYZCert ClientAuthRequired
SSLCertificate www.xyz.com XYZCert ClientAuthRequired
CN="valid.user.common.name.pattern" && (L="accepted.location.pattern" ||
C!="not.valid.country.pattern")
Aucune
S'applique aux configurations avec proxy inversé uniquement.
Cette directive permet d'indiquer au serveur proxy qu'une carte de chiffrement est installée et de quelle carte il s'agit.
Sous AIX, pour prendre en charge la carte IBM 4960 PCI Cryptographic Accelerator Card, voir PKCS11DefaultCert, PKCS11DriverPath, PKCS11TokenPassword — Prend en charge la carte IBM 4960 PCI Cryptographic Accelerator Card (AIX uniquement).
SSLCryptoCard {rainbowcs | nciphernfast} {on | off}
SSLCryptoCard rainbowcs on
Aucune
Cette directive permet d'indiquer que Caching Proxy est à l'écoute des demandes sécurisées sur le port 443.
SSLEnable {on | off}
SSLEnable off
Cette directive permet de spécifier le port auquel s'adresser dans le cas de demandes HTTP devant être mises à niveau en demandes HTTPS par Caching Proxy en implémentant le protocole SSL. Spécifiez un port différent du port HTTP principal 80 et du port SSL principal 443.
SSLForwardPort numéro de port
SSLForwardPort 8888
Aucune
Cette directive permet de désactiver les unités d'exécution à l'écoute pour les demandes HTTP standard (généralement les ports 80 et 8080) lorsque le SSL (généralement le port 443) est activé.
SSLOnly {on | off}
SSLOnly off
Utilisez cette directive pour indiquer un port d'écoute HTTPS autre que le port par défaut HTTPS (443) d'ibmproxy.
SSLPort valeur du port
où valeur du port est un nombre entier supérieur à 0. La valeur du port doit être admise par le système d'exploitation et ne doit pas être utilisée par une autre application.
SSLPort 8443
443
S'applique aux configurations avec proxy d'acheminement uniquement.
Lorsque cette directive a la valeur on, l'établissement de tunnels SSL est autorisé sur n'importe quel port du serveur de destination. Lorsqu'elle a la valeur off, l'établissement de tunnels SSL est possible uniquement sur les ports définis dans les règles Proxy. S'il n'existe aucune règle Proxy pour l'établissement de tunnels SSL et que la directive SSLTunneling a la valeur off, cette fonction n'est pas autorisée. Si la directive SSLTunneling possède la valeur on, vous devez également activer la méthode CONNECT à l'aide de la directive Enable.
Activez cette directive si vous utilisez Caching Proxy comme proxy d'acheminement. Toutefois, lorsque vous utilisez Caching Proxy comme proxy inversé, la désactivation de cette directive (option par défaut) permet de vous protéger contre les attaques de tunnels SSL.
Pour plus d'informations, voir Etablissement de tunnels SSL.
SSLTunneling {on | off}
SSLTunneling off
Cette directive permet de spécifier la version SSL à utiliser V2, V3 ou n'importe quelle version. Affectez à cette directive la valeur V2 si vous utilisez des serveurs ne prenant pas en charge SSL version 3.
SSLVersion {SSLV2 | SSLV3 | all}
SSLVersion SSLV3
Cette directive permet d'indiquer, en secondes, le délai d'inactivité au-delà duquel une session SSL version 3 expire.
SSLV2Timeout secondes
où secondes est une valeur comprise entre 0 et 100.
SSLV2Timeout 100
Cette directive permet d'indiquer, en secondes, le délai d'inactivité au-delà duquel une session SSL version 3 expire.
SSLV3Timeout secondes
où secondes est une valeur comprise entre 1 et 86400 secondes (1 jour exprimé en secondes).
SSLV3Timeout 100
Cette directive permet d'indiquer si le serveur fait une distinction entre les majuscules et les minuscules lorsqu'il compare les extensions de fichier aux modèles d'extensions dans les directives AddClient, AddCharSet, AddType, AddEncoding et AddLanguage. Par défaut, les majuscules et les minuscules ne sont pas différenciées.
SuffixCaseSense {on | Off}
SuffixCaseSense Off
Cette directive autorise Caching Proxy à mettre en cache plusieurs variantes d'une ressource (URI) sur la base de l'en-tête HTTP Vary.
Lorsque la directive SupportVaryHeader est activée, le proxy crée un ID de cache fondé sur l'URI et les valeurs d'en-tête sélectionnées dans la demande client.
Les noms des en-têtes sélectionnés sont spécifiés dans l'en-tête Vary envoyé dans une réponse précédente du serveur. Si le serveur modifie l'ensemble des noms d'en-tête sélectionnés pour une ressource, tous les objets mis en cache précédemment pour la ressource sont supprimés du cache du proxy.
Cette directive peut être utilisée en association avec la directive RegisterCacheIdTransformer (RegisterCacheIdTransformer — Met en cache plusieurs variantes d'une ressource sur la base de l'en-tête Cookie).
Lorsque ces deux directives sont utilisées, le proxy crée un convertisseur d'ID de cache interne fondé sur l'en-tête Vary provenant de l'en-tête de la demande du serveur et du client. Le serveur proxy peut ainsi générer des identificateurs de cache uniques pour des paires de demande et de réponse différentes même si les URI demandés sont identiques.
Les objets mis en cache dotés du même URI ont une durée de conservation en cache par défaut différente, qui dépend des en-têtes Expire et Cache-Control dans les demandes/réponses ou d'autres paramètres de configuration. Si le plug-in Dynacache est utilisé, toutes les présentations multiples associées au même URI perdent leur validité simultanément dans la mémoire cache du proxy.
SupportVaryHeader {on | off}
Dans cet exemple, les directives suivantes sont activées et configurées dans le fichier ibmproxy.conf, comme indiqué ci-dessous :
SupportVaryHeader on
RegisterCacheIdTransformer Cookie UserGroup
L'utilisateur Guest (invité) du client accède au serveur proxy avec
URI [<code>] http://www.dot.com/group.jpg [</code>]
et la demande/réponse suivante :
GET /group.jpg HTTP/1.1
Host: www.dot.com
Cookie: UserGroup=Guest
Accept-Language: en_US
HTTP/1.1 200
Server: my-server
Vary: Accept-Language
.......
L'utilisateur Admin du client accède ensuite au serveur proxy avec le même URI
http://www.dot.com/group.jpg
et la demande/réponse suivante :
GET /group.jpg HTTP/1.1
Host: www.dot.com
Cookie: UserGroup=Admin
Accept-Language: fr_FR
HTTP/1.1 200
Server: my-server
Vary: Accept-Language
.......
Ainsi, si la réponse peut être mise en cache, le serveur proxy génère deux ID de cache différents :
1. CacheID(URI, "Guest", "en_US")
2. CacheID(URI, "Admin", "fr_FR")
Le serveur proxy enregistre en mémoire cache deux variantes différentes de la réponse du serveur. Ainsi, lorsqu'un client demande la ressource (.../group.jpg), avec n'importe quelle combinaison de valeurs de préférence de langue et de groupe utilisateur, le serveur proxy extrait du cache la variante appropriée de la ressource et l'envoie au client.
SupportVaryHeader off
Cette directive permet d'activer le protocole TLS version 1 pour les connexions SSL. Une fois cette directive activée, la connexion SSL vérifie d'abord le protocole TLS, puis le protocole SSLv3 et enfin le protocole SSLv2.
TLSV1Enable {on | off}
TLSV1Enable on
Aucune
Cette directive permet de spécifier une fonction d'application personnalisée devant être appelée par le serveur lors de l'étape de manipulation des données. Ce code fournit trois fonctions d'application :
Plusieurs directives Transmogrifier peuvent être actives dans chaque instance du serveur.
Transmogrifier /chemin/fichier:nom_fonction:nom_fonction:nom_fonction
Transmogrifier
/ics/bin/icsext05.so:open_data:write_data:close_data:error_data
Aucune
Utilisez cette directive pour envoyer au client un message relatif aux données :
transmogrifiedwaning {yes|no}
Yes
S'applique aux configurations avec proxy d'acheminement uniquement.
Pour les systèmes Linux uniquement, utilisez cette directive pour spécifier si le serveur peut s'exécuter comme un serveur proxy transparent.
Lorsque la directive TransparentProxy est définie sur on, la directive BindSpecific est ignorée et prend par défaut la valeur off. La plupart des données HTTP étant acheminées sur le port 80, il est conseillé que ce dernier soit l'un des ports configurés.
TransparentProxy {on | off}
Port 80
TransparentProxy off
En cas d'utilisation du pare-feu IPCHAIN, l'activation de la directive suffit à configurer le proxy transparent. En cas d'utilisation du pare-feu IPTABLES, vous devez ajouter manuellement la règle du pare-feu IPTABLES.
Si vous utilisez le pare-feu IPTABLES, à l'activation de la directive TransparentProxy et avant de démarrer le serveur proxy, exécutez la commande suivante pour ajouter la règle de pare-feu dans IPTABLES :
iptables -t nat -A PREROUTING -i votre-interface-réseau -p tcp --dport 80 -j
REDIRECT --to-port port-écoute-proxyibm
En supposant que le pare-feu et le serveur proxy se trouvent dans la même zone, cette règle demande au pare-feu IPTABLES de rediriger tout le trafic TCP indiqué pour le port 80 sur le port d'écoute du proxy local. Vous pouvez également ajouter la règle dans la configuration IPTABLES. La règle peut ainsi se charger automatiquement au redémarrage du système.
Si, après avoir démarré le proxy transparent, vous voulez arrêter le serveur Caching Proxy, vous devez également lancer la commande suivante en tant qu'utilisateur root :
ibmproxy -unload
Sous Linux, cette commande supprime les règles de pare-feu de réacheminement. Si vous ne lancez pas cette commande après l'arrêt du serveur, votre machine acceptera des demandes qui ne lui sont pas destinées.
Cette directive permet d'identifier le serveur proxy que l'agent de la mémoire cache doit mettre à jour. Elle est requise lorsque l'agent de la mémoire cache doit mettre à jour un serveur proxy autre que le serveur proxy local sur lequel il est exécuté. Vous pouvez éventuellement spécifier le port.
S'il est capable de mettre à jour la mémoire cache sur un autre serveur, l'agent de la mémoire cache ne peut pas récupérer le journal des accès à la mémoire cache sur cette machine. Ainsi, si la directive UpdateProxy spécifie un hôte autre que l'hôte local, la directive LoadTopCached est ignorée.
UpdateProxy nom d'hôte complet du serveur proxy
UpdateProxy proxy15.ibm.com:1080
Aucune
Cette directive permet de spécifier le nom ou le numéro de l'utilisateur auquel accède serveur avant d'accéder aux fichiers.
Si vous changez cette directive, vous devez arrêter manuellement le serveur puis le redémarrer pour que le changement soit effectif. La modification n'est pas prise en compte si vous redémarrez le serveur sans l'arrêter. (Voir Démarrage et arrêt de Caching Proxy.)
UserId {nom_ID | numéro}
AIX, Linux, Solaris : UserId nobody
HP-UX : UserId www
Cette directive donne la liste des spécifications de chiffrement disponibles pour SSL version 2.
V2CipherSpecs spécification
Toutes les associations de valeurs suivantes sont admises. Aucune ne peut être utilisée deux fois.
Aucun (SSL est désactivé par défaut.)
Cette directive affiche la liste des spécifications de chiffrement disponibles pour SSL version 3.
Si la directive FIPSenable a la valeur "on", la directive V3CipherSpecs est ignorée. Pour plus d'informations, voir FIPSEnable — Codes de chiffrement conformes à la norme FIPS (Enable Federal Information Processing Standard) pour SSLV3 et TLS.
V3CipherSpecs spécification
Les valeurs admises sont les suivantes :
Aucun (SSL est désactivé par défaut.)
Cette directive permet de définir une adresse électronique à laquelle recevoir des rapports d'un Caching Proxy sélectionné, tel un avertissement 30 jours avant l'expiration d'un certificat SSL. Sous Linux et UNIX, un processus sendmail doit être actif. Sous Windows, le processus sendmail est intégré à Caching Proxy, de sorte qu'aucun serveur de messagerie externe n'est requis. Deux directives supplémentaires doivent toutefois être définies : WebMasterSocksServer (Windows uniquement)— Configure un serveur socks pour la routine sendmail et SMTPServer (Windows uniquement)— Configure un serveur SMTP pour la routine sendmail.
WebMasterEMail adresse_électronique_webmaster
WebMasterEmail webmaster@computer.com
WebMasterEmail webmaster
Cette directive permet de configurer le serveur socks qu'utilise la routine interne sendmail dans le cadre de Caching Proxy pour Windows. Cette routine nécessite également la définition des directives WebMasterEMail — Définit une adresse électronique pour la réception des rapports d'un serveur sélectionné et SMTPServer (Windows uniquement)— Configure un serveur SMTP pour la routine sendmail.
WebMasterSocksServer adresse IP ou nom d'hôte du serveur socks
WebMasterSocksServer socks.mybox.com
Aucune
Cette directive permet de spécifier le nom d'un fichier de bienvenue que le serveur doit rechercher pour répondre à des demandes qui ne contiennent pas de nom de fichier. Vous pouvez créer une liste de fichiers de bienvenue en insérant plusieurs occurrences de cette directive dans le fichier de configuration.
Lorsque les demandes ne contiennent pas de nom de fichier ou de répertoire, le serveur recherche dans le répertoire principal des fichiers un fichier dont le nom correspond à l'un de ceux indiqués dans une directive Welcome. Si une correspondance est trouvée, le fichier est renvoyé au demandeur.
Si le serveur trouve plusieurs correspondances entre les noms de fichier d'un répertoire et ceux des directives Welcome, l'ordre d'apparition des directives Welcome détermine le fichier renvoyé. Le serveur utilise la première directive Welcome du fichier de configuration.
Welcome nom_fichier [adresse_IP_serveur | nom_hôte]
Vous pouvez spécifier une adresse IP (par exemple, 240.146.167.72) ou un nom d'hôte (par exemple, hostA.bcd.com).
Ce paramètre est facultatif. Sans ce paramètre, le serveur utilise la directive pour toutes les demandes, quelle que soit l'adresse IP d'où elles proviennent ou le nom d'hôte de l'URL.
Il n'est pas possible d'indiquer de caractère générique pour une adresse IP de serveur.
Welcome CustomerA.html 0.67.106.79
Welcome CustomerB.html 0.83.100.45
Welcome CustomerA.html hôteA.bcd.com
Welcome CustomerB.html hôteB.bcd.com
Ces valeurs par défaut sont indiqués dans l'ordre utilisé par le fichier de configuration.
Welcome Welcome.html
Welcome welcome.html
Welcome index.html
Welcome Frntpage.html