Hallo und willkommen zurück.
Im heutigen Video werden wir über die benutzerdefinierten Fehlerseiten in Cloud Front sprechen.
Im Allgemeinen ist eine Kundenfehlerseite eines der wichtigsten Elemente, nicht nur speziell für die Cloud-basierte
Umgebung, sondern für jede Website, die Sie haben.
Es ist wichtig, dass Sie die Kundenseiten einstellen, also lassen Sie uns damit beginnen und einen Blick darauf werfen.
Schauen wir uns also zunächst die allgemeine Herausforderung an.
In einer Cloud-basierten Architektur gibt es einen Ursprung und einen Client.
So werden der Statuscode und die Fehlerseite, die Cloud Friend vom Ursprung erhält, auch an den Betrachter zurückgegeben.
Und auch hier kann es sein, dass dies nicht zu den besten Erfahrungen führt.
In diesem Screenshot sehen Sie zum Beispiel, dass der Benutzer eine Datei mit dem Namen test txt angefordert hat, und in
der Antwort ist eine x HTML-basierte Antwort mit dem Hinweis, dass der Zugriff verweigert wurde, und es werden verschiedene Dinge wie
die Anforderungs-ID, die Host-ID usw. angezeigt.
Im Allgemeinen möchten Sie bei Websites nicht, dass diese Art von Antwort an den Benutzer zurückgegeben wird.
Sie benötigen eine allgemeinere Antwort, die Ihnen zugestellt werden sollte.
Hier kommen also die benutzerdefinierten Fehlerseiten ins Spiel.
Jetzt können Sie Cloud Print so konfigurieren, dass es eine benutzerdefinierte Fehlerantwort an den Viewer sendet, die sich
von der ursprünglichen Antwort unterscheidet.
Dies lässt sich anhand dieses Diagramms besser nachvollziehen: Sie haben einen Nutzer, einen
Cloud Print und drei Buckets, in denen eine Art Website gehostet wird.
Der Nutzer sendet also eine Anfrage an die Cloud, die Druckwolke sendet die Anfrage an den Ursprung und sendet eine
Antwort zurück an die Cloud-Firma mit der Angabe http 403 access denied.
In diesem Stadium kann die Cloud-Front, wenn sie die Daten empfängt, verschiedene Antworten konfigurieren, die an den
Benutzer gesendet werden.
Wenn Sie also sehen, dass die Antwort anders ist, einschließlich des Statuscodes.
Hier ist der HTTP-Statuscode also für null drei Zugriff verweigert.
Der von der Cloud-Firma gesendete Statuscode lautet jedoch Null vier, was nicht gefunden wird.
Also gut.
Lassen Sie uns also eine Sache tun.
Schauen wir uns das einmal praktisch an.
Wenn Sie sich größere Websites ansehen, finden Sie in der Regel eine Art benutzerdefinierte Fehlerseite,
zum Beispiel in der Dokumentation.
Wenn wir einfach nach einem Objekt fragen, das nicht existiert, anstatt die Schriftart 404 naught zu verwenden, sehen Sie, dass Sie eine sehr
schöne Antwort erhalten, die auch hilfreich ist und viel bessere Informationen liefert.
Wenn Sie in einer Cloud-Distribution, die nicht über die konfigurierte benutzerdefinierte Fehlerseite verfügt, eine Anforderung
für ein nicht vorhandenes Objekt stellen, sollten Sie es ausprobieren.
Sie sehen also, dass Sie die typische XML-Antwort erhalten haben, die besagt, dass der Zugriff verweigert wurde und so weiter.
Dies ist also etwas, das Sie nicht an Ihre Nutzer zurückschicken wollen.
Stattdessen konfigurieren Sie eine benutzerdefinierte Fehlerseite auf der Cloud-Print-Ebene und die Antwort kann verbessert
werden.
Jetzt habe ich eine weitere Cloud-Firm-Distribution mit einer benutzerdefinierten Fehlerseite, die konfiguriert
ist. Ersetzen wir also die URL durch die neuere Distribution und fügen wir hier einen beliebigen Text ein.
Drücken Sie die Eingabetaste, und Sie werden sehen, dass die Antwort dieses Mal etwas anders ausfällt.
Dort steht, dass die Seite leider nicht verfügbar ist.
Sie können hier eine viel sauberere Seite haben.
Der Einfachheit halber habe ich hier nur ein Textdokument mit den Details eingefügt, und auf Websites haben
Sie dann so etwas wie das hier oder eine Art Bild, das die Sache viel besser aussehen lässt.
Ich möchte Ihnen auch kurz zeigen, wie Sie dies konfigurieren können.
Der Einfachheit halber habe ich also eine Cloud-Verteilung, die wiederum mit dem Ursprung des S3-Buckets
verknüpft ist.
Die Website wird also in S3 gehostet.
Wenn Sie sich jetzt die Verteilung und die Fehlerseite ansehen, habe ich eine Fehlerseite, die hier konfiguriert
ist.
Dies besagt, dass, wenn der Cloud-Freund eine 403-Zugriff verweigert erhält, was diese spezielle Seite
ist, die wir zuvor gesehen haben, anstatt diese zu senden, nur die Antwort gesendet wird, die Teil der benutzerdefinierten
Fehlerseiten-HTML-Datei ist.
Und wo diese Datei gespeichert wird, ist sie in demselben wie drei Buckets gespeichert.
Sie haben also eine benutzerdefinierte HTML-Fehlerseite.
Daher wird diese Datei anstelle von 403 zurückgegeben.
Wenn alles funktioniert, wird unsere Index-HTML-Datei zurückgegeben.
Ein weiterer interessanter Aspekt ist, dass sich auch der HTTP-Statuscode ändert.
Hier lautet der Fehlercode also 403.
Der HTTP-Antwortcode ist hier jedoch für Null vier.
Anstatt dem Benutzer eine Nachricht über die Verweigerung des Zugriffs zu senden, sendet Cloud Front eine "Seite nicht gefunden".
Und auch das kann konfiguriert werden.
Schauen wir uns das auch schnell an.
Lassen Sie uns also eine Sache tun.
Kehren wir zur Verteilung zurück.
In einer der Verteilungen ist die benutzerdefinierte Fehlerseite konfiguriert.
Bei der zweiten ist die benutzerdefinierte Fehlerseite nicht konfiguriert.
Schauen wir uns zunächst die Cloud-Distribution an, bei der die Fehlerseite von Scylla noch nicht konfiguriert
ist.
Wenn ich schnell eine Locke zum.
Verteilung und wir wissen, dass das Objekt nicht existiert.
Schauen wir uns die Kopfzeile an.
Die Kopfzeile hier ist für Null drei verboten.
Schauen wir uns nun die Cloud-Distribution an, in der die Fehlerseite konfiguriert ist.
Ich werde noch einmal einen Antrag auf Locken stellen.
Sie senden es an ein Objekt, das nicht wirklich existiert.
Im Idealfall senden drei diese 4034-Rückmeldung an den Cloud-Freund zurück.
Diesmal sehen Sie jedoch, dass der HTTP-Statuscode ebenfalls auf 404 geändert wurde.
Dies ist also etwas, das Sie auch auf der Cloud-Ebene leicht konfigurieren können.
Wenn Sie nun die Fehlerseiten konfigurieren.
Sie müssen den HTTP-Fehlercode definieren.
Wenn der Ursprung beispielsweise diese 404-nicht-gefunden-Meldung zurück an die Cloud-Front sendet, können Sie die
Fehlermeldung hier anpassen.
Und hier können Sie angeben, welche Datei zurückgegeben werden soll.
In diesem Fall handelt es sich um eine benutzerdefinierte HTML-Fehlerseite, die Sie einfach hier angeben können.
Außerdem gibt es die Möglichkeit, einen anderen HTTP-Statuscode zu senden.
Anstelle von 404 not found by the origin können Sie also etwas wie 400 bad requests oder einen anderen Statuscode
je nach Anforderungsraster angeben.
Dies ist also ein sehr umfassender Überblick über das Zurücksenden der benutzerdefinierten Fehlerantwort an den Betrachter.
Und damit endet das heutige Video.