Lors de la réception d'une demande client, Caching Proxy effectue l'action indiquée dans la zone méthode sur l'objet indiqué dans la zone URL, à condition que la méthode demandée ait été activée. Le serveur proxy résout l'URL à l'aide d'un jeu de règles de mappages définies par l'administrateur. Ces règles de mappage ordonnent à Caching Proxy de jouer le rôle d'un serveur Web et de récupérer l'objet à partir du système de fichiers local, ou de jouer le rôle d'un serveur proxy et de récupérer l'objet sur le serveur d'origine.
Ce traite de l'activation de méthodes, de la définition de règles de mappage et de la configuration d'un serveur proxy de substitution.
Les demandes que les clients transmettent au serveur comprennent une zone Méthode indiquant l'action que le serveur doit effectuer sur l'objet indiqué.
La liste ci-après répertorie les méthodes acceptées par le serveur proxy, ainsi qu'une description de la réponse du serveur proxy à une demande contenant une méthode activée.
Pour des informations sur le format et les options disponibles pour la méthode Enable CONNECT, voir Configuration de l'établissement des tunnels SSL.
La méthode POST est conçue pour gérer l'annotation de ressources existantes. Elle permet notamment d'envoyer un message à un tableau d'affichage, un forum, une liste d'adresses ou un autre groupe de ressources similaire, d'envoyer un bloc de données, par exemple d'un formulaire vers un programme de gestion de données, ou encore d'étendre une base de données via une opération d'ajout append. Pour Caching Proxy, la méthode POST permet de traiter les formulaires de configuration et d'administration.
Cette méthode permet de gérer les connexions permanentes.
L'activation de la méthode PUT permet de copier les fichiers sur le composant Caching Proxy à l'aide des protocoles HTTP et FTP. Dans la mesure où la méthode PUT permet aux clients d'écrire sur Caching Proxy, vous devez utiliser les configurations de protection du serveur pour définir les personnes autorisées à utiliser cette méthode ainsi que le type de fichier traité. (Voir Configurations de protection du serveur.)
Les directives suivantes activent les méthodes HTTP/FTP :
Pour plus d'informations, voir Modification manuelle du fichier ibmproxy.conf.
Les formulaires de configuration et d'administration suivants modifient les valeurs des directives associées :
Pour plus d'informations, voir Utilisation des formulaires de configuration et d'administration.
S'applique aux configurations avec proxy inversé uniquement.
Outre la prise en charge des méthodes HTTP standard, Caching Proxy accepte l'acheminement d'autres méthodes définies dans des spécifications RFC ou utilisées par certaines applications. Caching Proxy prend également en charge des méthodes définies par l'utilisateur et permet leur acheminement via le serveur proxy.
WebDAV (Web-based Distributed Authoring and Versioning) est un ensemble d'extensions du protocole HTTP qui vous permet de modifier et de gérer des fichiers sur des serveurs Web distants de façon collaborative. Caching Proxy prend en charge les méthodes WebDAV, les méthodes utilisées par Microsoft Exchange Server et les méthodes définies par l'utilisateur (personnalisées).
Ces méthodes sont définies dans le code et sont gérées par les directives Enable et Disable. Les administrateurs peuvent également utiliser le masque de méthode correspondant défini dans la directive PROTECT pour autoriser l'utilisation de ces méthodes.
Méthodes WebDAV prises en charge (RFC 2518) : PROPFIND , PROPPATCH , MKCOL, COPY, MOVE, LOCK, UNLOCK, SEARCH
Méthodes MS Exchange prises en charge : BMOVE, BCOPY, BDELETE, BPROPFIND, BPROPPATCH, POLL, NOTIFY, SUBSCRIBE, UNSUBSCRIBE, ACL, SUBSCRIPTIONS, X_MS_ENUMATTS
Lorsque la méthode WebDAV ou MS Exchange Server est activée, Caching Proxy achemine les demandes aux serveurs cible uniquement et ne réécrit aucun lien de ressource dans le corps de la demande.
Caching Proxy peut également acheminer au serveur dorsal des méthodes définies par l'utilisateur. Pour activer une méthode personnalisée, appliquez la syntaxe suivante à la directive Enable dans le fichier ibmproxy.conf :
Enable méthode définie par l'utilisateur [WithBody | WithoutBody]
La définition d'une valeur pour WithBody ou WithoutBody indique au proxy si la méthode définie par l'utilisateur exige un corps de demande.
Dans l'exemple suivant, la méthode définie par l'utilisateurMa_METHODE est activée et le proxy est informé qu'elle a besoin d'un corps de demande :
Enable Ma_METHODE WithBody
Les directives suivantes activent les méthodes WebDAV, les méthodes MS Exchange ainsi que les méthodes définies par l'utilisateur :
Pour plus d'informations, voir Modification manuelle du fichier ibmproxy.conf.
Les règles de mappage sont des directives de configuration définissant la façon dont Caching Proxy traite les demandes client, comme leur transfert au serveur origine, leur redirection ou leur refus. La définition de règles de mappage adéquates est essentielle dans le fonctionnement de Caching Proxy. Les règles de mappage ont un effet sur les actions suivantes :
Les directives de règles de mappage se présentent dans le format suivant :
règle modèle cible [adresse_IP | nom_hôte]:[port]
Seules les demandes correspondant au modèle et à la combinaison IP-port donnés sont concernées par cette règle. Un modèle peut contenir des caractères génériques ; https://**/*.asp, par exemple.
L'ordre d'apparition des règles dans le fichier de configuration est très important. Sauf pour les directives Map, dès qu'une demande correspond à un modèle, elle est traitée sans que les autres règles soient évaluées. La directive Map remplace l'URL dans la demande. Cette nouvelle demande est comparée aux autres règles de mappage.
Les règles de mappage suivantes s'appliquent aux demandes client correspondant au modèle donné :
La règle de mappage suivante s'applique à la réaction du serveur origine :
Les règles de mappage suivantes s'appliquent aux applications d'API :
Pour configurer un serveur de substitution standard, procédez comme suit :
Port 80
Proxy /* http://serveur.de.données.com/* :80
AdminPort 8080
Ceci permet de transmettre au serveur origine tout le trafic HTTP du port 80. Le trafic entrant sur le port d'administration n'est pas concerné par cette opération car il ne correspond pas à la règle de proxy générique initiale. La demande est traitée par les autres règles de mappage.
Les directives suivantes définissent des règles de mappage :
Pour plus d'informations, voir Modification manuelle du fichier ibmproxy.conf.
Le formulaire de configuration et d'administration suivant modifie les valeurs des directives associées :
Pour plus d'informations, voir Utilisation des formulaires de configuration et d'administration.
S'applique aux configurations avec proxy inversé uniquement.
La directive JunctionRewrite active la routine de réécriture de jonction au sein de Caching Proxy pour réécrire les réponses provenant des serveurs d'origine et garantir le mappage des URL de serveur au serveur d'origine approprié lors de l'utilisation de jonctions. Le plug-in de réécriture de jonction doit également être activé. Les jonctions sont définies à l'aide des règles de mappage du proxy.
Lorsque vous utilisez les règles de mappage du serveur proxy pour définir la jonction, vous pouvez utiliser la directive Proxy avec ou sans l'option JunctionPrefix.
Voici des exemples de jonctions correctes que la routine de réécriture de jonction est capable de traiter :
L'exemple suivant est un exemple de jonction valide qui n'est pas traité par la routine de réécriture de jonction :
Les jonctions suivantes sont incorrectes :
Ces règles de mappage ont créé des jonctions pour shopserver, authserver et b2bserver. Supposons que shopserver renvoie un document HTML avec les URL suivantes dans les codes HTML appropriés :
La routine de réécriture de jonction réécrit les références liées au serveur à l'aide des règles de mappage du proxy, comme suit :
Lorsque vous utilisez l'option JunctionPrefix avec la directive Proxy, 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 l'élément JunctionPrefix en fonction du premier modèle d'URL.
Proxy modèle1_url modèle2_url JunctionPrefix:préfixe_url
Lorsque vous utilisez JunctionPrefix, il n'y a pas de limitation pour le format du premier modèle d'URL. Pour permettre la prise en charge de la réécriture de jonction lorsque vous n'utilisez pas l'option JunctionPrefix, l'URL de proxy doit posséder le format suivant : Proxy /market/* http://b2bserver/*. Toutefois, lorsque vous utilisez JunctionPrefix, la règle Proxy suivante s'applique à la réécriture de jonction :
Proxy /market/partners/*.html http://b2bserver.acme.com/*.html
junctionprefix:/market/partners
La routine de réécriture de jonction affecte les codes suivants :
Code | Attributs |
---|---|
!— | URL |
a | href |
applet | archive, codebase |
area | href |
base | href |
body | background |
del | cite |
embed | pluginspage |
form | action |
input | src |
frame | src, longdesc |
iframe | src, longdesc |
ilayer | src, background |
img | src, usemap, lowsrc, longdesc, dynsrc |
layer | src, background |
link | href |
meta | url |
object | data, classid, codebase, codepage |
script | src |
table | background |
td | background |
th | background |
tr | background |
Les directives suivantes permettent d'activer le plug-in et la routine de réécriture de jonction.
Pour plus d'informations, voir Modification manuelle du fichier ibmproxy.conf.
Le formulaire de configuration et d'administration suivant permet d'activer le plug-in de réécriture de jonction :
Pour plus d'informations, voir Utilisation des formulaires de configuration et d'administration.
Vous pouvez utiliser des cookies pour stocker les informations de serveur dorsal de la façon suivante : un cookie est envoyé au navigateur client. Lorsque le navigateur envoie des requêtes aux ressources de la page HTML, il y associe un cookie pour que le composant Caching Proxy transmette les requêtes au serveur dorsal approprié.
Pour utiliser des cookies à la place de la directive JunctionRewrite, apportez les modifications ci-dessous au fichier ibmproxy.conf.
Vous trouverez ci-après une comparaison du plug-in JunctionRewrite et de l'implémentation des cookies.
Proxy /no-juntion.jpg http://login-server/no-junction.jpg
Un exemple de code personnalisable est fourni et permet de réécrire et d'analyser les blocs de balises JavaScript (SCRIPT) et d'applet (APPLET) dans les fichiers HTML. Seul, le plug-in JunctionRewrite ne peut pas traiter les liens de ressources dans JavaScript ou dans les valeurs de paramètres de Java.
Une fois Caching Proxy installé, vous pouvez compiler le même code et le configurer de sorte qu'il s'exécute avec JunctionRewrite.
Les fichiers exemple ci-dessous se trouvent dans le sous-répertoire ...samples/cp/, dans le répertoire dans lequel vous avez téléchargé le correctif (fix pack).