L'interface API permet d'étendre les fonctions de base du serveur proxy. En créant des modules d'extension, vous pouvez effectuer des traitements personnalisés tels que ceux répertoriés ci-dessous.
La procédure de base d'émission des demandes vers le serveur peut être répartie en plusieurs étapes, dépendant du type de traitement réalisé par le serveur durant cette phase. Chaque étape comprend une jonction à l'emplacement de laquelle la partie de programme indiquée peut s'exécuter. En ajoutant les directives API à votre fichier de configuration, vous définissez les fonctions d'application auxquelles le serveur doit faire appel lors d'une étape spécifique. Pour appeler plusieurs fonctions d'application au cours d'une étape de transmission des demandes au serveur, incluez plusieurs directives de l'interface API pour cette étape.
Le programme compilé se trouve dans un fichier .DLL, .so ou .o selon le système d'exploitation utilisé. Alors que le serveur effectue les étapes de traitement des demandes, il appelle les fonctions d'application d'extension associées à chaque étape jusqu'à ce que l'une des fonctions indique qu'elle a traité la demande. Lorsque plusieurs fonctions d'extension sont appelées lors d'une étape donnée, celles-ci sont appelées dans l'ordre où elles apparaissent dans le fichier de configuration.
Si la demande n'est pas satisfaite par une fonction d'application (aucune fonction d'application n'est indiquée ou la fonction d'application correspondant à cette étape a renvoyé le code HTTP_NOACTION), le serveur exécute l'action par défaut qui correspond à cette étape. Remarque : Cela est vrai pour toutes les étapes, sauf pour l'étape Service, qui n'est associée à aucune action par défaut.
Chaque étape de transmission des demandes est associée à une directive de configuration qui permet d'indiquer la fonction d'application personnalisée devant être appelée et exécutée au cours de cette étape.
Lorsque plusieurs fonctions d'extension sont appelées lors d'une étape de traitement, l'ordre relatif de ces directives peut revêtir une certaine importance. Les fonctions correspondant à une étape sont en effet exécutées dans l'ordre où elles sont répertoriées.
Les directives NameTrans et Service fonctionnent comme la directive Exec. Leur présence et leur position par rapport aux autres directives de mappage dans le fichier de configuration sont déterminantes. Ainsi, le serveur traite les directives Service, NameTrans, Map, Pass, Exec, Redirect, et Fail dans l'ordre successif dans lequel elles figurent dans le fichier de configuration. Lorsque le serveur parvient à associer une URL à un fichier, il ne lit ni ne traite les autres directives correspondant à la demande.
Remarque : Les directives NameTrans et Service, ainsi que Map, Pass, Exec, Redirect et Fail, peuvent être configurées à l'aide du formulaire Request Routing. Le formulaire non modifié contient les paramètres par défaut des directives ci-dessus, classés dans l'ordre approprié.
ServerInit | chemin/fichier:nom_fonction | ||
PreExit | chemin/fichier:nom_fonction | ||
Authentication | Type | chemin/fichier:nom_fonction | |
NameTrans | /URL | chemin/fichier:nom_fonction | |
Authorization | /URL | chemin/fichier:nom_fonction | |
ObjectType | /URL | chemin/fichier:nom_fonction | |
PostAuth | chemin/fichier:nom_fonction | ||
Service | /URL | chemin/fichier:nom_fonction | |
Transmogrifier | /chemin/fichier:nom_fonction_ouverture:nom_fonction_écriture:nom_fonction_fermeture:nom_fonction_erreur | ||
Log | /URL | chemin/fichier:nom_fonction | |
Erreur | /URL | chemin/fichier:nom_fonction | |
PostExit | chemin/fichier:nom_fonction | ||
ServerTerm | chemin/fichier:nom_fonction | ||
Midnight | chemin/fichier:nom_fonction | ||
PICSDBLookup | chemin/fichier:nom_fonction | ||
GC Advisor | chemin/fichier:nom_fonction | ||
Proxy Advisor | chemin/fichier:nom_fonction |
Remarque : Vous devez indiquer un modèle d'URL pour la directive Service afin que les chemins d'accès soient convertis.