Benutzerdefinierte Verwaltung von Netzwerkanforderungen

Mit dem Microsoft Edge WebView2-Steuerelement können Sie mit Netzwerkanforderungen interagieren und diese ändern. Sie können entweder eine Antwort bereitstellen oder die Netzwerkanforderung mithilfe der WebResourceRequested Ereignisse and WebResourceResponseReceived ändern.

Mit der NavigateWithWebResourceRequest Methode können Sie über bestimmte Netzwerkanforderungen navigieren.

Detaillierter Inhalt:

Einführung

Mit dem Microsoft Edge WebView2-Steuerelement können Sie mit Netzwerkanforderungen interagieren und diese ändern. Sie können entweder eine Antwort bereitstellen oder die Netzwerkanforderung mithilfe der WebResourceRequested Ereignisse and WebResourceResponseReceived ändern.

Mit der NavigateWithWebResourceRequest Methode können Sie über bestimmte Netzwerkanforderungen navigieren.

Sie können Netzwerkanforderungen wie unten beschrieben ändern. Verwenden Sie die NavigateWithWebResourceRequest Methode für folgende Zwecke:

  • Laden Sie lokale Dateiinhalte in Ihre App hoch, um die Unterstützung für Offlinefunktionen hinzuzufügen.

  • Blockieren Sie Inhalte auf einer Webseite, z. B. bestimmte Bilder.

  • Optimieren Sie die Authentifizierung für bestimmte Seiten.

Terminologie:

Begriff Definition
Abfangen Ihre Host-App kann eine Anforderung abfangen, die vom WebView2-Steuerelement an den HTTP-Server gesendet wird, die Anforderung lesen oder ändern und dann die unveränderte oder geänderte Anforderung an den HTTP-Server (oder an lokalen Code anstelle des HTTP-Servers) senden.
Außerkraftsetzen Ihre Host-App kann eine Antwort, die vom HTTP-Server an das WebView2-Steuerelement gesendet wird, außer Kraft setzen und eine benutzerdefinierte Antwort an das WebView2-Steuerelement statt der ursprünglichen Antwort senden.

Wann sollten benutzerdefinierte Ansätze im Vergleich zu grundlegenden Ansätzen verwendet werden?

Das WebResourceRequested Ereignis ist eine Low-Level-API, die mehr Kontrolle bietet, jedoch mehr Codierung erfordert und kompliziert zu verwenden ist. Für einige gängige Szenarien stellen wir APIs bereit, die einfacher zu verwenden und für diese spezifischen Szenarien optimiert sind. Es wird daher empfohlen, diese APIs anstelle der in diesem Artikel beschriebenen APIs zu verwenden.

Anstatt die WebResourceRequested-APIs zu verwenden, ist es vorzuziehen, diese anderen Ansätze zu verwenden, wenn dies möglich ist:

Hinweis: Bei URLs mit virtuellen Hostnamen wird die Verwendung des WebResourceRequested Ereignisses nicht unterstützt. Dies liegt daran, dass das WebResourceRequested Ereignis nicht für die SetVirtualHostNameToFolderMapping-Methode ausgelöst wird.

Interaktion Ihrer Host-App, des WebView2-Steuerelements und des HTTP-Servers

Das WebView2-Steuerelement befindet sich zwischen Ihrer Host-App und dem HTTP-Server. Wenn Ihre Host-App zu einem URI navigiert, sendet das WebView2-Steuerelement eine Anforderung an den HTTP-Server. Der HTTP-Server sendet dann eine Antwort an das WebView2-Steuerelement.

Abfangen einer Anforderung, um sie zu überwachen oder zu ändern

Ihre Host-App kann eine Anforderung abfangen , die vom WebView2-Steuerelement an den HTTP-Server gesendet wird, die Anforderung lesen oder ändern und dann die unveränderte oder geänderte Anforderung an den HTTP-Server (oder an lokalen Code anstelle des HTTP-Servers) senden.

Durch das Abfangen der Anforderung können Sie den Headerinhalt, die URL oder die GET/POST-Methode anpassen. Die Host-App möchte möglicherweise eine Anforderung abfangen, um optionalen POST-Inhalt als Teil der Anforderung bereitzustellen.

Die Host-App kann die Eigenschaften einer Anforderung mithilfe dieser API ändern:

Möglichkeiten mit Kopfzeilen

Ein HTTP-Header stellt wichtige Informationen und Metadaten zu einer Anforderung oder Antwort bereit. Durch das Ändern von Headern können Sie leistungsstarke Aktionen im Netzwerk ausführen.

Ein Anforderungsheader kann verwendet werden, um das Format der Antwort (z. B. die Accept-* Header) anzugeben, Authentifizierungstoken festzulegen, Cookies (vertrauliche Informationen) zu lesen und zu schreiben, den Benutzer-Agent zu ändern und so weiter. Ein Antwortheader kann verwendet werden, um mehr Kontext für die Antwort bereitzustellen.

Filtern des WebResourceRequested-Ereignisses basierend auf URL und Ressourcentyp

Um Ereignisse zu empfangen WebResourceRequested , geben Sie Filter für die Anforderungen an, an denen die Host-App basierend auf URL und Ressourcentyp interessiert ist.

Angenommen, die Host-App versucht, Bilder zu ersetzen. In diesem Fall ist die Host-App nur an WebResourceRequested Ereignissen für Bilder interessiert. Die Host-App ruft nur Ereignisse für Bilder ab, indem der resourceContext Filter für Bilder angegeben wird.

Ein weiteres Beispiel ist, wenn die Host-App nur an allen Anforderungen interessiert ist, die sich unter einer Site wie https://example.combefinden. Dann kann die App einen URL-Filter https://example.com/* angeben, um Ereignisse abzurufen, die dieser Website zugeordnet sind.

Einzelheiten zur Funktionsweise des URL-Filters finden Sie unter Hinweise zur CoreWebView2.AddWebResourceRequestedFilter-Methode >

Warum sollten Sie Anforderungen abfangen, die von WebView2 gesendet werden?

Durch das Abfangen von Anforderungen, die von WebView2 gesendet werden, können Sie Ihre Anforderung weiter konfigurieren. Die Host-App möchte möglicherweise optionale Inhalte als Teil der Anforderung bereitstellen, die das WebView2-Steuerelement nicht selbst kennt. Einige Szenarien umfassen:

  • Sie melden sich bei einer Seite an, und die App verfügt über Anmeldeinformationen, damit die App einen Authentifizierungsheader bereitstellen kann, ohne dass der Benutzer diese Anmeldeinformationen eingeben muss.
  • Sie möchten Offlinefunktionen in der App haben, also leiten Sie die URL zu einem lokalen Dateipfad um, wenn keine Internetverbindung erkannt wird.
  • Sie möchten lokale Dateiinhalte über eine POST-Anforderung auf den Anforderungsserver hochladen.

Sequenz zum Ändern von Anforderungen

Sequenzdiagramm zum Ändern von Anforderungen

  1. Die Host-App richtet einen WebResourceRequested Filter ein.
  2. Die Host-App definiert die Ereignishandler für WebResourceRequested und WebResourceResponseReceived.
  3. Die Host-App navigiert das WebView2-Steuerelement zu einer Webseite.
  4. Das WebView2-Steuerelement erstellt eine Anforderung für eine Ressource, die für die Webseite benötigt wird.
  5. Das WebView2-Steuerelement löst ein WebResourceRequested Ereignis an der Host-App aus.
  6. Die Host-App überwacht und verarbeitet das WebResourceRequested Ereignis.
  7. Die Host-App kann an diesem Punkt Header ändern. Die Host-App kann das WebResourceRequested Ereignis auch zurückstellen, was bedeutet, dass die Host-App mehr Zeit anfordert, um zu entscheiden, was getan werden soll.
  8. Der WebView2-Netzwerkstapel kann weitere Header hinzufügen (z. B. Cookies und Autorisierungsheader).
  9. Das WebView2-Steuerelement sendet die Anforderung an den HTTP-Server.
  10. Der HTTP-Server sendet die Antwort an das WebView2-Steuerelement.
  11. Das WebView2-Steuerelement löst das WebResourceResponseReceived Ereignis aus.
  12. Die Host-App lauscht auf das WebResourceResponseReceived Ereignis und behandelt es.

Beispiel: Abfangen einer Anforderung, um sie zu überwachen oder zu ändern

Im folgenden Beispiel fängt die Host-App die Dokumentanforderung ab , die vom WebView2-Steuerelement an den http://www.example.com HTTP-Server gesendet wird, fügt einen benutzerdefinierten Headerwert hinzu und sendet die Anforderung.

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

Überschreiben einer Antwort, um sie proaktiv zu ersetzen

Standardmäßig sendet der HTTP-Server Antworten an das WebView2-Steuerelement. Ihre Host-App kann eine Antwort, die vom HTTP-Server an das WebView2-Steuerelement gesendet wird, außer Kraft setzen und eine benutzerdefinierte Antwort an das WebView2-Steuerelement statt der ursprünglichen Antwort senden.

Sequenz zum Überschreiben von Antworten

Sequenzdiagramm zum Überschreiben von Antworten

  1. Die Host-App richtet einen WebResourceRequested Filter ein.
  2. Die Host-App definiert die Ereignishandler für WebResourceRequested und WebResourceResponseReceived.
  3. Die Host-App navigiert das WebView2-Steuerelement zu einer Webseite.
  4. Das WebView2-Steuerelement erstellt eine Anforderung für eine Ressource, die für die Webseite benötigt wird.
  5. Das WebView2-Steuerelement löst ein WebResourceRequested Ereignis an der Host-App aus.
  6. Die Host-App überwacht und verarbeitet das WebResourceRequested Ereignis.
  7. Die Host-App legt eine Antwort auf den WebResourceRequested Ereignishandler fest. Die Host-App kann das WebResourceRequested Ereignis auch zurückstellen, was bedeutet, dass die Host-App mehr Zeit anfordert, um zu entscheiden, was getan werden soll.
  8. Das WebView2-Steuerelement rendert die Antwort als Ressource.

Beispiel: Überschreiben einer Antwort, um sie proaktiv zu ersetzen

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

Erstellen einer benutzerdefinierten Anforderung und Navigieren mithilfe dieser Anforderung

Die NavigateWithWebResourceRequest Methode ermöglicht es Ihrer Host-App, im WebView2-Steuerelement mithilfe einer benutzerdefinierten WebResourceRequest. Sie können diese API verwenden, um eine GET- oder POST-Anforderung mit benutzerdefinierten Headern und Inhalten zu erstellen. Anschließend navigiert das WebView2-Steuerelement mithilfe dieser benutzerdefinierten Anforderung.

Beispiel: Erstellen einer benutzerdefinierten Anforderung und Navigieren mithilfe dieser Anforderung

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

Überwachen der Anforderungen und Antworten über das Ereignis "WebResourceResponseReceived"

Sie können die Anforderungen und Antworten über das WebResourceResponseReceived Ereignis überwachen, um einen beliebigen Headerwert zu lesen.

Beispiel: Überwachen der Anforderungen und Antworten über das Ereignis WebResourceResponseReceived

In diesem Beispiel wird gezeigt, wie Sie den Wert des Autorisierungsheaders lesen, indem Sie die Anforderungen und Antworten über das WebResourceResponseReceived Ereignis überwachen.

Der folgende Code veranschaulicht, wie das WebResourceResponseReceived Ereignis verwendet werden kann.

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.
        }
    }
}

Übersicht über API-Referenz

Anforderung:

Antwort:

Siehe auch