Stratégies

Chaque paramètre de stratégie, policy, définit une stratégie d'accès pour un modèle d'URL donné. Spécifiez le modèle à l'aide de l'attribut url. Un attribut url peut être une URL, le caractère générique, ou une partie d'URL qui se termine par le caractère générique "*". Les exemples suivants sont des valeurs d'attribut d'URL : http://localhost/index.html *http://www.ibm.com/developerWorks/*.

L'exemple suivant présente une stratégie simple :
<proxy-rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://www.ibm.com/xmlns/prod/sw/http/outbound/proxy-config/2.0">        
     <policy name="SamplePolicy" url="http://www.myremotehost.com/*">
          <actions><method>GET</method></actions>
     </policy>
</policy-rules>

Pour chaque demande entrante, le proxy applique la stratégie avec la meilleure correspondance d'URL. Si le proxy détecte une stratégie, il l'applique à la connexion sortante. Si le proxy ne détecte aucune stratégie correspondante, le proxy rejette la demande. Les mappages peuvent éventuellement déclarer un paramètre de stratégie, policy, qui représente les stratégies d'accès spécifiques du mappage.

Un paramètre de stratégie, policy, peut avoir un attribut name qui identifie cette stratégie pour les tâches d'administration. Si cet attribut n'est pas défini, le portail définit un nom d'administration unique. Le nom d'administration doit être unique pour toutes les stratégies ayant le même paramètre parent mapping ou proxy-rules.

Pour activer l'authentification de base pour une stratégie, vous pouvez affecter la valeur true à l'attribut basic-auth-support.

Un paramètre de stratégie, policy, peut comporter les sous-paramètres affichés dans la liste suivante. Dans le fichier de configuration proxy-config.xml, indiquez ces sous-paramètres dans l'ordre donné ci-dessous :
actions
Ce paramètre est obligatoire. Utilisez-le pour définir la liste des méthodes HTTP pouvant être utilisées pour accéder à des ressources dans le domaine cible. Ces méthodes sont GET, HEAD, POST, PUT et DELETE. Le proxy refuse les demandes qui utilisent des méthodes HTTP uniquement dans cette liste. Indiquez chaque méthode HTTP à l'aide d'un paramètre method distinct. L'exemple suivant illustre une stratégie qui prend en charge les méthodes DELETE, GET, HEAD, POST et PUT :
<proxy-rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://www.ibm.com/xmlns/prod/sw/http/outbound/proxy-config/2.0">
     <policy name="SamplePolicy_supporting_all_methods" url="http://www.myremotehost.com/*">
          <actions>
               <method>GET</method>
               <method>HEAD</method>
               <method>POST</method>
               <method>PUT</method>
               <method>DELETE</method>
          </actions>
     </policy>
</policy-rules>
en-têtes
Ce paramètre est facultatif. Utilisez-le pour définir la liste des noms d'en-têtes que le proxy doit transmettre au domaine cible. Les noms d'en-tête peuvent comporter des caractères génériques. Si vous ne spécifiez pas de noms d'en-tête pour la stratégie, le proxy par défaut réachemine les en-têtes qui correspondent aux expressions de nom suivantes : Cache-Control, Pragma, User-Agent, Accept*, Host et Content*. Indiquez chaque nom d'en-tête à l'aide d'un paramètre header distinct.
Remarque : La valeur Cookies n'est pas admise. Utilisez à la place le paramètre cookie-rules afin d'indiquer le comportement de transfert des cookies pour la stratégie.
L'exemple suivant illustre une stratégie qui prend en charge l'en-tête X-Method-Override :
<proxy-rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:noNamespaceSchemaLocation="http://www.ibm.com/xmlns/prod/sw/http/outbound/proxy-config/2.0">
     <policy name="SamplePolicy_custom_header_added" url="http://www.myremotehost.com/*">
          <actions><method>GET</method></actions>

          <headers>
               <header>X-Method-Override</header>
          </headers>
     </policy>
</proxy-rules>
mime-types
Ce paramètre est facultatif. Utilisez-le pour indiquer la liste des types mime acceptés. Les types mime désignent la réponse que le proxy reçoit du serveur cible. Si vous indiquez au moins un type MIME, le proxy accepte uniquement des réponses avec un en-tête Content-Type correspondant à l'un des types MIME indiqués. Si vous n'indiquez aucun type MIME, le proxy accepte toutes les réponses. Indiquez chaque type MIME à l'aide d'un paramètre mime-type distinct. Les serveurs peuvent ajouter le codage de caractères au type MIME. Par conséquent, il peut être utile d'utiliser des caractères génériques lorsque vous indiquez des types MIME. Par exemple, si vous indiquez text/html*, le proxy accepte aussi des réponses avec Content-Type text/html; charset=utf-8. L'exemple suivant présente une règle qui utilise le filtrage de types mime :
<proxy-rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://www.ibm.com/xmlns/prod/sw/http/outbound/proxy-config/2.0">
     <policy name="SamplePolicy_filtered_mimetype" url="http://www.myremotehost.com/*">
          <actions><method>GET</method></actions>

          <mime-types>
               <mime-type>text/plain</mime-type>
          </mime-types>
     </policy>
</proxy-rules>