Partager via

Gestion personnalisée des demandes réseau

  • Article

Le contrôle Microsoft Edge WebView2 vous permet d’interagir avec les demandes réseau et de les modifier. Vous pouvez fournir une réponse ou modifier la requête réseau à l’aide des WebResourceRequested événements et WebResourceResponseReceived . Il existe également des fonctionnalités spéciales qui vous permettent de naviguer avec des requêtes réseau spécifiques à l’aide de NavigateWithWebResourceRequest API.

Cet article décrit comment vous pouvez modifier les demandes réseau. Utilisez cette API et cette approche pour :

  • Chargez le contenu du fichier local dans votre application pour ajouter la prise en charge des fonctionnalités hors connexion.
  • Bloquer le contenu d’une page web, par exemple des images spécifiques.
  • Affiner l’authentification pour des pages spécifiques.

Terminologie:

Terme Définition
Intercepter Votre application hôte peut intercepter une requête envoyée du contrôle WebView2 au serveur HTTP, lire ou modifier la requête, puis envoyer la requête inchangée ou modifiée au serveur HTTP (ou au code local au lieu du serveur HTTP).
Substituer Votre application hôte peut remplacer une réponse envoyée du serveur HTTP au contrôle WebView2 et envoyer une réponse personnalisée au contrôle WebView2 au lieu de la réponse d’origine.

Quand utiliser des approches personnalisées et des approches de base

L’événement WebResourceRequested est une API de bas niveau qui donne plus de contrôle, mais nécessite davantage de codage et est compliqué à utiliser. Pour certains scénarios courants, nous fournissons des API plus faciles à utiliser et optimisées pour ces scénarios spécifiques, et nous vous recommandons d’utiliser ces API plutôt que les API décrites dans cet article.

Au lieu d’utiliser les API WebResourceRequested, il est préférable d’utiliser ces autres approches dans la mesure du possible :

Note: Pour les URL avec des noms d’hôte virtuels, l’utilisation de l’événement WebResourceRequested n’est pas prise en charge. En effet, l’événement WebResourceRequested n’est pas déclenché pour la méthode SetVirtualHostNameToFolderMapping.

Comment votre application hôte, le contrôle WebView2 et le serveur HTTP interagissent

Le contrôle WebView2 se trouve entre votre application hôte et le serveur HTTP. Lorsque votre application hôte accède à un URI, le contrôle WebView2 envoie une requête au serveur HTTP. Le serveur HTTP envoie ensuite une réponse au contrôle WebView2.

Interception d’une requête, pour la surveiller ou la modifier

Votre application hôte peut intercepter une requête envoyée du contrôle WebView2 au serveur HTTP, lire ou modifier la requête, puis envoyer la requête inchangée ou modifiée au serveur HTTP (ou au code local au lieu du serveur HTTP).

L’interception de la requête vous permet de personnaliser le contenu de l’en-tête, l’URL ou la méthode GET/POST. L’application hôte peut vouloir intercepter une requête pour fournir du contenu POST facultatif dans le cadre de la demande.

L’application hôte peut modifier les propriétés d’une requête à l’aide de cette API :

Ce que vous pouvez faire avec les en-têtes

Un en-tête HTTP fournit des informations et des métadonnées importantes sur une demande ou une réponse. La modification des en-têtes vous permet d’effectuer des actions puissantes sur le réseau.

Un en-tête de requête peut être utilisé pour indiquer le format de la réponse (par exemple, les Accept-* en-têtes), définir des jetons d’authentification, lire et écrire des cookies (informations sensibles), modifier l’agent utilisateur, etc. Un en-tête de réponse peut être utilisé pour fournir davantage de contexte de la réponse.

Filtrage de l’événement WebResourceRequested en fonction de l’URL et du type de ressource

Pour recevoir WebResourceRequested des événements, spécifiez des filtres pour les demandes qui intéressent l’application hôte, en fonction de l’URL et du type de ressource.

Par exemple, supposons que l’application hôte tente de remplacer des images. Dans ce cas, l’application hôte s’intéresse uniquement aux WebResourceRequested événements pour les images. L’application hôte obtient uniquement les événements pour les images en spécifiant le resourceContext filtre pour les images.

Un autre exemple est si l’application hôte s’intéresse uniquement à toutes les requêtes qui se trouvent sous un site comme https://example.com. L’application peut ensuite spécifier un filtre d’URL pour https://example.com/* obtenir les événements associés à ce site.

Pour plus d’informations sur le fonctionnement du filtre d’URL, consultez Remarques sur la méthode > CoreWebView2.AddWebResourceRequestedFilter

Pourquoi voulez-vous intercepter les demandes envoyées à partir de WebView2 ?

L’interception des requêtes envoyées à partir de WebView2 vous permet de configurer davantage votre demande. L’application hôte peut souhaiter fournir du contenu facultatif dans le cadre de la demande que le contrôle WebView2 ne connaîtra pas lui-même. Voici quelques scénarios :

  • Vous vous connectez à une page et l’application possède des informations d’identification afin que l’application puisse fournir un en-tête d’authentification sans que l’utilisateur ait à entrer ces informations d’identification.
  • Vous souhaitez une fonctionnalité hors connexion dans l’application afin de rediriger l’URL vers un chemin d’accès de fichier local lorsqu’aucune connexion Internet n’est détectée.
  • Vous souhaitez charger le contenu du fichier local sur le serveur de requêtes via une requête POST.

Séquence de modification des demandes

Diagramme de séquence pour la modification des demandes

  1. L’application hôte configure un WebResourceRequested filtre.
  2. L’application hôte définit les gestionnaires d’événements pour WebResourceRequested et WebResourceResponseReceived.
  3. L’application hôte navigue le contrôle WebView2 vers une page web.
  4. Le contrôle WebView2 crée une demande pour une ressource nécessaire pour la page web.
  5. Le contrôle WebView2 déclenche un WebResourceRequested événement sur l’application hôte.
  6. L’application hôte écoute et gère l’événement WebResourceRequested .
  7. L’application hôte peut modifier les en-têtes à ce stade. L’application hôte peut également différer l’événement WebResourceRequested , ce qui signifie que l’application hôte demande plus de temps pour décider ce qu’elle doit faire.
  8. La pile réseau WebView2 peut ajouter d’autres en-têtes (par exemple, peut ajouter des cookies et des en-têtes d’autorisation).
  9. Le contrôle WebView2 envoie la requête au serveur HTTP.
  10. Le serveur HTTP envoie la réponse au contrôle WebView2.
  11. Le contrôle WebView2 déclenche l’événement WebResourceResponseReceived .
  12. L’application hôte écoute l’événement WebResourceResponseReceived et le gère.

Exemple : Interception d’une requête, pour la surveiller ou la modifier

Dans l’exemple suivant, l’application hôte intercepte la demande de document envoyée du contrôle WebView2 au http://www.example.com serveur HTTP, ajoute une valeur d’en-tête personnalisée et envoie la requête.

// Add a filter to select all resource types under http://www.example.com
webView.CoreWebView2.AddWebResourceRequestedFilter(
      "http://www.example.com/*", CoreWebView2WebResourceContext.All);
webView.CoreWebView2.WebResourceRequested += delegate (
   object sender, CoreWebView2WebResourceRequestedEventArgs args) {
   CoreWebView2WebResourceContext resourceContext = args.ResourceContext;
   // Only intercept the document resources
   if (resourceContext != CoreWebView2WebResourceContext.Document)
   {
      return;
   }
   CoreWebView2HttpRequestHeaders requestHeaders = args.Request.Headers;
   requestHeaders.SetHeader("Custom", "Value");
};

Remplacement d’une réponse, pour la remplacer de manière proactive

Par défaut, le serveur HTTP envoie des réponses au contrôle WebView2. Votre application hôte peut remplacer une réponse envoyée du serveur HTTP au contrôle WebView2 et envoyer une réponse personnalisée au contrôle WebView2 au lieu de la réponse d’origine.

Séquence de substitution des réponses

Diagramme de la séquence de remplacement des réponses

  1. L’application hôte configure un WebResourceRequested filtre.
  2. L’application hôte définit les gestionnaires d’événements pour WebResourceRequested et WebResourceResponseReceived.
  3. L’application hôte navigue le contrôle WebView2 vers une page web.
  4. Le contrôle WebView2 crée une demande pour une ressource nécessaire pour la page web.
  5. Le contrôle WebView2 déclenche un WebResourceRequested événement sur l’application hôte.
  6. L’application hôte écoute et gère l’événement WebResourceRequested .
  7. L’application hôte définit une réponse au gestionnaire d’événements WebResourceRequested . L’application hôte peut également différer l’événement WebResourceRequested , ce qui signifie que l’application hôte demande plus de temps pour décider ce qu’elle doit faire.
  8. Le contrôle WebView2 restitue la réponse en tant que ressource.

Exemple : remplacement d’une réponse pour la remplacer de manière proactive

// Add a filter to select all image resources
webView.CoreWebView2.AddWebResourceRequestedFilter(
      "*", CoreWebView2WebResourceContext.Image);
webView.CoreWebView2.WebResourceRequested += delegate (
   object sender, CoreWebView2WebResourceRequestedEventArgs args) {
    
   // Replace the remote image resource with a local one specified at the path customImagePath.
   // If response is not set, the request will continue as it is.
   FileStream fs = File.Open(customImagePath, FileMode.Open);
   CoreWebView2WebResourceResponse response = webView.CoreWebView2.Environment.CreateWebResourceResponse(fs, 200, "OK", "Content-Type: image/jpeg");
   args.Response = response;
};

Construction d’une requête personnalisée et navigation à l’aide de cette demande

La NavigateWithWebResourceRequest méthode permet à votre application hôte de naviguer dans le contrôle WebView2 à l’aide d’un personnalisé WebResourceRequest. Vous pouvez utiliser cette API pour créer une requête GET ou POST avec des en-têtes et du contenu personnalisés. Ensuite, le contrôle WebView2 naviguera à l’aide de cette requête personnalisée.

Exemple : construction d’une requête personnalisée et navigation à l’aide de cette demande

// This code posts text input=Hello to the POST form page in W3Schools.

// Need to convert post data to UTF-8 as required by the application/x-www-form-urlencoded Content-Type 
UTF8Encoding utfEncoding = new UTF8Encoding();
byte[] postData = utfEncoding.GetBytes("input=Hello");

MemoryStream postDataStream = new MemoryStream(postData.Length);
postDataStream.Write(postData, 0, postData.Length);
postDataStream.Seek(0, SeekOrigin.Begin);

// This acts as a HTML form submit to https://www.w3schools.com/action_page.php
CoreWebView2WebResourceRequest webResourceRequest = 
environment.CreateWebResourceRequest("https://www.w3schools.com/action_page.php",
                                     "POST",
                                     postDataStream,
                                    "Content-Type: application/x-www-form-urlencoded");
webView.CoreWebView2.NavigateWithWebResourceRequest(webResourceRequest);

Surveillance des demandes et des réponses via l’événement WebResourceResponseReceived

Vous pouvez surveiller les demandes et les réponses via l’événement WebResourceResponseReceived pour lire n’importe quelle valeur d’en-tête.

Exemple : surveillance des demandes et des réponses via l’événement WebResourceResponseReceived

Cet exemple montre comment lire la valeur d’en-tête d’autorisation en surveillant les demandes et les réponses via l’événement WebResourceResponseReceived .

Le code suivant montre comment l’événement WebResourceResponseReceived peut être utilisé.

WebView.CoreWebView2.WebResourceResponseReceived += CoreWebView2_WebResourceResponseReceived;

// Note: modifications made to request are set but have no effect on WebView processing it.
private async void WebView_WebResourceResponseReceived(object sender, CoreWebView2WebResourceResponseReceivedEventArgs e)
{
    // Actual headers sent with request
    foreach (var current in e.Request.Headers)
    {
        Console.WriteLine(current);
    }

    // Headers in response received
    foreach (var current in e.Response.Headers)
    {
        Console.WriteLine(current);
    }

    // Status code from response received
    int status = e.Response.StatusCode;
    if (status == 200)
    {
        Console.WriteLine("Request succeeded!");

        // Get response body
        try
        {
            System.IO.Stream content = await e.Response.GetContentAsync();
            // Null will be returned if no content was found for the response.
            if (content != null)
            {
                DoSomethingWithResponseContent(content);
            }
        }
        catch (COMException ex)
        {
            // A COMException will be thrown if the content failed to load.
        }
    }
}

Vue d’ensemble des informations de référence sur les API

Demande:

Réponse:

Voir aussi