Gestion du traitement des demandes

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.

Activation des méthodes HTTP/FTP

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.

Remarque :
Certaines méthodes s'appliquent aux demandes HTTP et FTP. L'activation de ces méthodes pour HTTP entraîne également leur activation pour FTP.

CONNECT
La méthode CONNECT permet d'acheminer par tunnel les demandes et les réponses via le serveur proxy. S'applique aux configurations avec proxy d'acheminement uniquement.

Pour des informations sur le format et les options disponibles pour la méthode Enable CONNECT, voir Configuration de l'établissement des tunnels SSL.

DELETE
Le serveur proxy supprime l'objet identifié par l'adresse URL. DELETE permet aux clients de supprimer des fichiers de Caching Proxy. Vous devez utiliser les configurations de protection pour définir les personnes autorisées à lancer cette méthode, ainsi que le type de fichiers à traiter. Pour plus d'informations, voir Configurations de protection du serveur.
GET
Le serveur proxy renvoie les données identifiées par l'adresse URL. Si l'adresse URL fait référence à un programme exécutable, le proxy renvoie les données générées par ce programme. Cette méthode permet de gérer les connexions permanentes.
HEAD
Le serveur proxy ne renvoie que l'en-tête de document HTTP identifié par l'URL, mais pas le corps du document.
OPTIONS
Le serveur proxy renvoie des informations sur les options de communication de la chaîne demande-réponse identifiée par l'adresse URL. Cette méthode permet au client de déterminer les options et les contraintes associées à un objet, ainsi que les fonctions du serveur sans avoir à intervenir ou à extraire l'objet.
POST
La demande contient des données et une adresse URL. Le serveur proxy accepte les données de la demande comme le nouveau subordonné de la ressource identifiée dans l'adresse URL qui traite les données. La ressource peut être un programme d'acceptation des données, une passerelle vers un autre protocole ou un programme distinct acceptant les commentaires.

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.

PUT
La demande contient des données et une adresse URL. Le serveur proxy stocke les données dans la ressource identifiée dans l'URL. Si la ressource existe déjà, la méthode PUT la remplace par les données contenues dans la demande. Si la ressource n'existe pas, elle la crée et y entre les données contenues dans la demande. 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.)

TRACE
Le serveur proxy répercute le message de la demande envoyée par le client. Cette méthode permet au client de voir ce qui est reçu à l'autre extrémité de la chaîne et d'utiliser ces données à des fins de test ou de diagnostic. Le type de contenu de la réponse du proxy est message/http.

Directives associées

Les directives suivantes activent les méthodes HTTP/FTP :

Pour plus d'informations, voir Modification manuelle du fichier ibmproxy.conf.

Formulaires de configuration et d'administration

Les formulaires de configuration et d'administration suivants modifient les valeurs des directives associées :

Remarque :
Si vous désactivez la méthode POST, vous ne pourrez pas utiliser les formulaires de configuration et d'administration pour configurer Caching Proxy.

Pour plus d'informations, voir Utilisation des formulaires de configuration et d'administration.

Méthodes Enable WebDAV, méthodes MS Exchange et méthodes définies par l'utilisateur

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

Directives associées

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.

Définition de règles de mappage

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.

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 :

Configuration d'un serveur de substitution

Pour configurer un serveur de substitution standard, procédez comme suit :

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.

Directives associées

Les directives suivantes définissent des règles de mappage :

Pour plus d'informations, voir Modification manuelle du fichier ibmproxy.conf.

Formulaires de configuration et d'administration

Le formulaire de configuration et d'administration suivant modifie les valeurs des directives associées :

Remarque :
L'argument numéro de port n'est pas pris en charge par les formulaires de configuration et d'administration.

Pour plus d'informations, voir Utilisation des formulaires de configuration et d'administration.

Activation de la réécriture de jonction (facultatif)

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.

Définition de la jonction 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 :

Définition de la jonction avec l'option JunctionPrefix (méthode recommandée)

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 :

Tableau 3. Codes affectés par la routine de réécriture de jonction
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
Remarque :
La routine de réécriture de jonction n'affecte pas les codes générés par JavaScript ou par des plug-ins au sein du navigateur.

Directives associées

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.

Formulaires de configuration et d'administration

Le formulaire de configuration et d'administration suivant permet d'activer le plug-in de réécriture de jonction :

Remarque :
La directive JunctionRewrite n'est pas prise en charge par les formulaires de configuration et d'administration.

Pour plus d'informations, voir Utilisation des formulaires de configuration et d'administration.

Utilisation de cookies à la place de JunctionRewrite

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.

  1. Remplacez JunctionRewrite on par JunctionRewrite on UseCookie.
  2. Mettez entre commentaires le plug-in JunctionRewrite.

Vous trouverez ci-après une comparaison du plug-in JunctionRewrite et de l'implémentation des cookies.

Exemple de plug-in transmogrifier pour l'extension de la fonctionnalité JunctionRewrite

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