Gestion personnalisée des requêtes réseau

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 demande de réseau à l’aide des WebResourceRequested événements et WebResourceResponseReceived .

Vous pouvez naviguer via des requêtes réseau spécifiques à l’aide de la NavigateWithWebResourceRequest méthode.

Contenu détaillé :

Introduction

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 demande de réseau à l’aide des WebResourceRequested événements et WebResourceResponseReceived .

Vous pouvez naviguer via des requêtes réseau spécifiques à l’aide de la NavigateWithWebResourceRequest méthode.

Vous pouvez modifier les demandes réseau, comme décrit ci-dessous. Utilisez la NavigateWithWebResourceRequest méthode pour :

  • Chargez du contenu de fichier local dans votre application pour ajouter la prise en charge de la fonctionnalité hors connexion.

  • Bloquer le contenu d’une page web, comme des images spécifiques.

  • Ajustez l’authentification pour des pages spécifiques.

Terminologie :

Terme Définition
Intercepter Votre application hôte peut intercepter une demande envoyée du contrôle WebView2 au serveur HTTP, lire ou modifier la demande, puis envoyer la demande inchangée ou modifiée au serveur HTTP (ou au code local au lieu du serveur HTTP).
Remplacer 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 l’approche personnalisée et l’approche de base

L’événement WebResourceRequested est une API de bas niveau qui donne plus de contrôle, mais nécessite plus de codage et est compliquée à 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 présentées dans cet article.

Au lieu d’utiliser les API WebResourceRequested, il est préférable d’utiliser ces autres approches lorsque cela est possible :

Remarque : Pour les URL avec des noms d’hôte virtuels, l’utilisation de l’événement WebResourceRequested n’est pas prise en charge. Cela est dû au fait que 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 demande envoyée du contrôle WebView2 au serveur HTTP, lire ou modifier la demande, puis envoyer la demande 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 souhaiter intercepter une demande de fourniture de contenu POST facultatif dans le cadre de la demande.

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

Actions possibles avec les en-têtes

Un en-tête HTTP fournit des informations et métadonnées importantes sur une requête 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 (comme 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 plus de contexte à 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 obtiendrait uniquement des événements pour les images en spécifiant le resourceContext filtre pour les images.

Un autre exemple est si l’application hôte est uniquement intéressée par toutes les demandes qui se trouvent sous un site comme https://example.com. Ensuite, l’application peut 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 CoreWebView2.AddWebResourceRequestedFilter Remarques sur la méthode >

Pourquoi voulez-vous intercepter les requêtes envoyées à partir de WebView2 ?

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

  • Vous vous connectez à une page et l’application a des informations d’identification, de sorte que l’application peut 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, de sorte que vous redirigez l’URL vers un chemin de fichier local lorsqu’aucune connexion Internet n’est détectée.
  • Vous souhaitez charger du contenu de fichier local sur le serveur de demande via une demande POST.

Séquence de modification des requêtes

Diagramme de séquence pour modifier les requêtes

  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. À ce stade, l’application hôte peut modifier les en-têtes. L’application hôte peut également différer l’événement WebResourceRequested , ce qui signifie qu’elle demande plus de temps pour décider de l’action à effectuer.
  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 demande 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 et le WebResourceResponseReceived 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 demande.

// 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");
};

Remplacer une réponse 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 pour remplacer les réponses

Diagramme de séquence pour remplacer les 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 qu’elle demande plus de temps pour décider de l’action à effectuer.
  8. Le contrôle WebView2 affiche 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 demande personnalisée et navigation à l’aide de cette demande

Cette NavigateWithWebResourceRequest méthode permet à votre application hôte de naviguer dans le contrôle WebView2 à l’aide d’un fichier .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 demande personnalisée.

Exemple : Construction d’une demande 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, pour lire n’importe WebResourceResponseReceived 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 de l’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 de la référence d’API

Demande :

Réponse :

Voir aussi

  • Dernière mise à jour :