Partager via


Modification des en-têtes de réponse HTTP

par Ruslan Yakushev

Cette section de la documentation s’applique au module de réécriture d’URL version 2.0 pour IIS 7.

Cette procédure pas à pas vous guide tout au long de l’utilisation du module de réécriture d’URL v 2.0 pour définir des en-têtes de réponse HTTP.

Prérequis

Cette procédure pas à pas nécessite les prérequis suivants :

  1. IIS 7 ou version ultérieure avec service de rôle ASP.NET activé ;
  2. Réécriture du module 2.0 version Release Candidate installée ;
  3. Procédure pas à pas terminée sur le proxy inverse avec la réécriture d’URL v2 et le routage des demandes d’application.

Introduction

Le module de réécriture d’URL 2.0 prend en charge la réécriture basée sur des règles des en-têtes HTTP de réponse. Un scénario d’utilisation très courant pour définir les en-têtes de réponse consiste à modifier la réponse de redirection générée par une application derrière un équilibreur de charge ou un proxy inverse. Par exemple, lorsqu’une application derrière un proxy inverse retourne une réponse de redirection, l’en-tête Emplacement HTTP dans la réponse peut ne pas représenter l’adresse accessible sur Internet, mais plutôt une adresse d’application interne. Le module de réécriture d’URL 2.0 peut être utilisé sur le serveur proxy inverse pour modifier l’en-tête Emplacement dans la réponse. Le scénario est représenté dans le diagramme suivant :

Diagram that shows the redirect response process among the client, reverse proxy server, and the internal client server.

  1. Un client HTTP effectue une requête à une page web http://www.contoso.com/webmail/oldpage.aspx.
  2. Le serveur proxy inverse utilise la réécriture d’URL 2.0 et le routage des demandes d’application pour transférer la requête vers un serveur de contenu interne en fonction du nom du dossier dans le chemin d’URL demandé. Par exemple, http://webmail/oldpage.aspx;
  3. L’application web qui s’exécute sur le serveur de contenu émet une réponse de redirection (HTTP/1.1 301) pointant un client HTTP vers http://webmail/newpage.aspx;
  4. Le serveur proxy inverse utilise la réécriture d’URL 2.0 pour remplacer l’emplacement de redirection interne dans la réponse par l’emplacement de redirection basé sur Internet : http://www.contoso.com/webmail/newpage.aspx.

Configuration d’un scénario de procédure pas à pas

Pour configurer le scénario de procédure pas à pas, suivez la procédure pas à pas sur proxy inverse avec la réécriture d’URL v2 et le routage des demandes d’application. À la fin de cette procédure pas à pas, vous devez disposer d’un site web de proxy inverse qui route les demandes vers deux applications de contenu : la messagerie web et la paie.

Pour cette procédure pas à pas, vous devez ajouter une logique de redirection à l’application de messagerie web. Dans un scénario réel, il s’agit probablement d’une redirection initiée par le code de l’application web, mais, par souci de simplicité, dans cette procédure pas à pas, vous allez utiliser une règle de redirection dans le module de réécriture d’URL.

  1. Créez un fichier nommé web.config dans le dossier suivant :

    %SystemDrive%\inetpub\webmail
    
  2. Ouvrez le fichier dans un éditeur de texte, collez le code XML suivant à l’intérieur, puis enregistrez le fichier :

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
    <system.webServer>
      <rewrite>
        <rules>
         <rule name="Redirect" stopProcessing="true">
         <match url="^index\.aspx$" />
         <action type="Redirect" url="default.aspx" />
        </rule>
       </rules>
      </rewrite>
    </system.webServer>
    </configuration>
    

    Il s’agit d’une règle qui redirige toutes les demandes de index.aspx vers default.aspx.

Ouvrez maintenant un navigateur web et effectuez une requête http://localhost/webmail/index.aspx. Notez que le navigateur a été redirigé vers http://localhost:8081/default.aspx, qui est essentiellement une URL interne utilisée par l’application web de messagerie web. Vous allez maintenant configurer les règles de réécriture d’URL pour modifier l’en-tête Emplacement HTTP dans les réponses de redirection HTTP afin que le navigateur soit redirigé vers une URL appropriée : http://localhost/webmail/default.aspx.

Modification de la règle de trafic entrant pour conserver l’en-tête de l’hôte

Pour pouvoir modifier l’en-tête d’emplacement HTTP, il est nécessaire de conserver la valeur d’origine de l’en-tête de l’hôte HTTP. La règle de réécriture sortante utilise la valeur conservée lors de la modification de la réponse. Pour conserver la valeur d’origine, stockez-la dans une variable de serveur temporaire ORIGINAL_HOST.

  1. Dans la page principale d’affichage des fonctionnalités de réécriture d’URL, sélectionnez Afficher les variables de serveur dans le volet Actions sur le côté droit :
    Screenshot of View Server Variables under Manage Server Variables in the Actions pane.
  2. Dans la page Variables de serveur autorisées, sélectionnez Ajouter, puis entrez le nom de la variable de serveur qui sera utilisée pour stocker temporairement la valeur de l’en-tête hôte HTTP. Par exemple, ORIGINAL_HOST :
    Screenshot of Server variable name set to ORIGINAL underscore HOST.
  3. Sélectionnez OK pour enregistrer les modifications, puis revenir à la page d’affichage principale de la fonctionnalité réécriture d’URL. Ensuite, sélectionnez la règle de trafic entrant « Proxy inverse vers la messagerie web », puis sélectionnez Modifier.
  4. Dans la page Modifier la règle de trafic entrant, développez la zone de groupe « Variables de serveur » ; sélectionnez ensuite Ajouter et entrez « ORIGINAL_HOST » pour le nom de la variable de serveur et « {HTTP_HOST} » pour la valeur :
    Screenshot of the Edit Inbound Rule page with Set Server Variable Value set to curly brace H T T P underscore HOST curly brace.

Création d’une règle de trafic sortant pour modifier l’en-tête de réponse HTTP

Vous allez maintenant créer une règle de réécriture sortante qui réécrit l’en-tête emplacement HTTP dans les réponses de redirection pour ajouter le dossier d’application au chemin d’URL et remplacer le nom d’hôte.

  1. Dans la page principale d’affichage des fonctionnalités de réécriture d’URL, sélectionnez « Ajouter des règles », puis sélectionnez « Règle vide » sous la catégorie « Règles de trafic sortant ».
  2. Dans la page «Modifier la règle sortante», nommez la règle « Réécrire l’en-tête d’emplacement ».
  3. Dans la liste déroulante «pré-condition», choisissez «<Créer une pré-condition> ».
  4. Dans la boîte de dialogue «Ajouter une pré-condition», nommez la condition préalable en tant que «IsRedirection»
  5. Sélectionnez «Ajouter», puis entrez {RESPONSE_STATUS} comme entrée de condition et «3\d\d» comme modèle. Cette pré-condition est utilisée pour vérifier si la réponse a un code d’état de redirection, tel que 301, 302, 307, etc. La boîte de dialogue de pré-condition doit ressembler à ce qui suit :
    Screenshot of curly brace RESPONSE underscore STATUS curly brace set as an input and 3 backslash d backslash d set as the pattern.
  6. Sélectionnez OK pour revenir à la page Modifier la règle de trafic sortant.
  7. Dans la zone de groupe Correspondance, utilisez la liste déroulante Étendue correspondante pour sélectionner Variable serveur.
  8. Entrez RESPONSE_Location pour « Nom de la variable » et « ^http://[^/]+/(.*) » pour le « Modèle ». Cela configure la règle pour qu’elle fonctionne sur l’en-tête HTTP de réponse « Emplacement » et corresponde à sa valeur par rapport à un modèle regex qui stocke le chemin d’URL dans une référence back-reference.
  9. Développez la zone de groupe «Conditions», sélectionnez «Ajouter» et entrez {ORIGINAL_HOST} comme entrée de condition et «+» comme modèle de condition. Cette condition vérifie si la variable de serveur temporaire ORIGINAL_HOST existe et a une valeur non vide.
  10. Sélectionnez Ajouter une fois de plus et ajoutez une autre condition. Définissez l’entrée de condition sur {URL} et le modèle sur «^/(webmail|payroll)/.*». Cette expression régulière est utilisée pour faire correspondre les chemins d’URL qui commencent par /webmail ou /payroll. En outre, la parenthèse dans le modèle capture la partie de la chaîne d’URL correspondante, afin qu’elle puisse être réutilisée lors de la construction de l’URL de remplacement.
  11. Enfin, dans la zone de groupe «Action», choisissez l’action «Réécrire» et entrez «http://{ORIGINAL_HOST}/{C:1}/{R:1}» comme valeur. Cette action remplace la valeur de l’en-tête d’emplacement HTTP par une chaîne construite à l’aide du nom d’hôte de la variable de serveur, de la condition de référence back-reference qui contient le préfixe du dossier du chemin d’accès d’URL et de la règle qui contient le chemin d’accès d’URL actuel dans l’en-tête Emplacement.

La page complète doit ressembler à ceci :

Screenshot of the Edit Outbound Rule pane with ORIGINAL HOST and U R L set as condition input.

Test de la règle

Pour tester que les règles fonctionnent correctement, ouvrez un navigateur web et effectuez une demande pour http://localhost/webmail/index.aspx. Le navigateur doit être redirigé vers http://localhost/webmail/default.aspx:

Screenshot of a web browser with the original U R L redirecting to the new U R L.

Résumé

Dans cette procédure pas à pas :

  • Vous avez appris à utiliser plusieurs nouvelles fonctionnalités dans la réécriture d’URL 2.0 pour implémenter un scénario de proxy inverse entièrement fonctionnel.
  • Vous avez configuré la règle de trafic entrant pour transférer les requêtes vers un serveur de contenu principal et définir une variable de serveur temporaire.
  • Vous avez ensuite défini une règle de trafic sortant qui modifie l’en-tête Emplacement HTTP dans la réponse de redirection générée par l’application web à partir du serveur de contenu principal.