CloudFront bietet zwei Mechanismen für den URL-Pfad.
Einer ist das Cache-Verhalten path pattern, das definiert, welche Pfade zu welchen Ursprüngen geroutet werden.
Die Pfadmuster /foo/* werden alle Anfragen senden /foo/* an den angegebenen Ursprungsabgleich, den Pfad in der ursprünglichen Anforderung verwenden, so GET /foo/bar auf die eingehende Anforderung wird, wie sie ist, GET /foo/bar auf die ausgehende Anfrage
zum Ursprung gesendet werden
... es sei denn ... der Pfad wird durch die origin path geändert, die dem Anfang jeder ausgehenden Anfrage an den Ursprung ein Präfix hinzufügt.
Wenn der Ursprung, oben, einen Ursprungspfad von /baz hatte, dann wäre die ausgehende Anfrage an den Ursprung GET /baz/foo/bar.
Es gibt also keinen Mechanismus zum Entfernen von Pfadkomponenten - nur zum Hinzufügen.
Keine Konfigurationsoptionen können Komponenten des Pfads entfernen, bevor die Anforderung an den Ursprung weitergeleitet wird. Wenn
GET /foo/bar an den Ursprung als
GET /bar weitergeleitet werden soll, verfügt CloudFront derzeit nicht über diese Funktion.
CloudFront selbst kann den Pfad, der an den Ursprung gesendet wird, nicht entfernen oder anderweitig neu schreiben, aber [email protected] tut dies. Lambda @ Edge ist ein CloudFront-Feature, mit dem Sie Trigger konfigurieren können, die während der Anforderungsverarbeitung an vier verschiedenen Punkten ausgelöst werden, und Teile der Anforderung (einschließlich Pfad und Header) oder Antwort (Header) mithilfe von in Node.js geschriebenem Code ändern .
CloudFront erstellt eine Datenstruktur, die die Anforderungsattribute darstellt, und ruft die Lambda-Funktion auf, wobei die Struktur als event-Argument übergeben wird. Die Antwort der Lambda-Funktion ändert das CloudFront-Verhalten entsprechend.
Es gibt 4 Triggerpunkte. Sie können jede Kombination von ihnen für jedes Cache-Verhalten verwenden.
- Viewer-Anfrage Trigger werden nach der ersten Anpassung des Cache-Verhalten Pfad Pattern Matching abgefeuert wird getan, aber bevor der Cache aktiviert ist. Hier können Sie die eingehende Anfrage vom Browser überprüfen, den Pfad und die Header ändern und sogar - abhängig vom Inhalt der Anfrage - eine einfache Antwort direkt aus der Lambda-Funktion generieren, die ohne weitere Bearbeitung an den Browser zurückgegeben wird von CloudFront. Wenn Sie den Pfad hier ändern, ändert sich der Pfad, den CloudFront für die Cache-Suche verwendet, aber nicht dazu, dass CloudFront ein anderes Cache-Verhalten auswählt. Nachdem der Cache überprüft wurde, kann im Falle eines Cache-Treffers eine Antwort an den Viewer zurückgegeben werden, oder die Verarbeitung kann in CloudFront fortgesetzt werden.
- Ursprungsanforderung löst aus, wenn CloudFront keine zwischengespeicherte Kopie des Objekts hat, bevor die Anforderung an den Ursprung gesendet wird. Pfad und Header können hier geändert werden, und einfache Antworten können direkt generiert werden, ohne dass die Anfrage bei Bedarf an den Ursprung gesendet wird. Dieser Trigger bewirkt nicht, dass sich die Cache-Verhalten-Auswahl ändert, selbst wenn Sie den Pfad neu schreiben. Wenn das erneute Schreiben von Pfaden erforderlich ist, ist dies in der Regel der kostengünstigste Auslöser, da es nur ausgelöst wird, wenn das Objekt nicht bereits im Cache vorhanden ist. (Im Gegensatz dazu wird der Viewer-Anforderungstrigger für jede Anforderung ausgelöst.)
- Ursprung Antwort löst Feuer aus, wenn die Antwort vom Ursprung zurückkehrt, bevor das Objekt zwischengespeichert und an den Viewer zurückgegeben wird. Hier können Sie die ursprüngliche Anfrage noch überprüfen, aber es ist zu spät, um sie zu ändern. Sie können die Antwortheader ändern. Dies ist besonders nützlich für Ursprünge, die die gewünschten Header
Cache-Control nicht festlegen. Das Festlegen von Cache-Control Headern beeinflusst hier sowohl das CloudFront- als auch das Browser-Cache-Verhalten. Dieser Auslöser löst keine Fehler aus, nur Ursprungsantworten mit HTTP-Statuscodes
- Viewer Antwort löst Feuer aus, bevor CloudFront ein Objekt an den Viewer zurückgibt, ob es vom Ursprung frisch abgerufen wurde oder vom Server stammt Zwischenspeicher. Antwortheader können geändert werden.
Für die Anwendung hier diskutiert, erfordert die Lösung eine Lambda @ Edge-Origin anfordern Trigger, einen bekannten Präfix aus dem Anforderungspfad nach die Cache aktiviert ist, aber vor die Anforderung entfernen gesendet zum Ursprungsserver.
Von Ihrer Beschreibung der Konfiguration wäre das einzige, was jetzt von Ursprung 2 zugänglich wäre, 'example2.com/Produtos/ns/*', auf das Sie mit 'cdn.example.com/ns/*' zugreifen würden. Was nicht so klingt wie du es beabsichtigt hast ... ist es? –
richtig, das wäre falsch ... Ich würde gerne auf orgin 2 wie cdn.mysite.com/ns/Productos/* zugreifen und das sollte auf example2.com/Productos/* <--- der ursprüngliche Pfad verweisen. –