Header
Header ermöglichen es Ihnen, benutzerdefinierte HTTP-Header für die Antwort auf eine eingehende Anfrage für einen bestimmten Pfad festzulegen.
Um benutzerdefinierte HTTP-Header festzulegen, können Sie den Schlüssel headers
in next.config.js
verwenden:
headers
ist eine asynchrone Funktion, die ein Array erwartet, das Objekte mit den Eigenschaften source
und headers
enthält:
source
ist das Pfadmuster der eingehenden Anfrage.headers
ist ein Array von Response-Header-Objekten mit den Eigenschaftenkey
undvalue
.basePath
:false
oderundefined
- wenn false, wird der basePath nicht beim Abgleich berücksichtigt, kann nur für externe Weiterleitungen verwendet werden.locale
:false
oderundefined
- ob das Gebietsschema beim Abgleich nicht berücksichtigt werden soll.has
ist ein Array von has-Objekten mit den Eigenschaftentype
,key
undvalue
.missing
ist ein Array von missing-Objekten mit den Eigenschaftentype
,key
undvalue
.
Header werden vor dem Dateisystem geprüft, einschließlich Seiten und /public
-Dateien.
Verhalten beim Header-Überschreiben
Wenn zwei Header denselben Pfad haben und denselben Header-Schlüssel setzen, überschreibt der letzte Header-Schlüssel den ersten. Bei den folgenden Headern wird der Pfad /hello
dazu führen, dass der Header x-hello
den Wert world
hat, da der zuletzt gesetzte Header-Wert world
ist.
Pfad-Matching
Pfad-Übereinstimmungen sind erlaubt, beispielsweise wird /blog/:slug
mit /blog/hello-world
übereinstimmen (keine verschachtelten Pfade):
Wildcard-Pfad-Matching
Um einen Wildcard-Pfad zu matchen, können Sie *
nach einem Parameter verwenden, beispielsweise wird /blog/:slug*
mit /blog/a/b/c/d/hello-world
übereinstimmen:
Regex-Pfad-Matching
Um einen Regex-Pfad zu matchen, können Sie den Regex in Klammern nach einem Parameter setzen, beispielsweise wird /blog/:slug(\\d{1,})
mit /blog/123
übereinstimmen, aber nicht mit /blog/abc
:
Die folgenden Zeichen (
, )
, {
, }
, :
, *
, +
, ?
werden für Regex-Pfad-Matching verwendet, daher müssen sie, wenn sie in der source
als Nicht-Sonderzeichen verwendet werden, mit einem \\
davor versehen werden:
Header, Cookie und Query-Matching
Um einen Header nur anzuwenden, wenn Header-, Cookie- oder Query-Werte ebenfalls mit dem has
-Feld übereinstimmen oder nicht mit dem missing
-Feld übereinstimmen, können has
und missing
verwendet werden. Sowohl die source
als auch alle has
-Elemente müssen übereinstimmen und alle missing
-Elemente dürfen nicht übereinstimmen, damit der Header angewendet wird.
has
- und missing
-Elemente können folgende Felder haben:
type
:String
- muss entwederheader
,cookie
,host
oderquery
sein.key
:String
- der Schlüssel des ausgewählten Typs, gegen den gemacht wird.value
:String
oderundefined
- der zu prüfende Wert, wenn nicht definiert, passt jeder Wert. Ein regex-ähnlicher String kann verwendet werden, um einen bestimmten Teil des Wertes zu erfassen, z.B. wenn der Wertfirst-(?<paramName>.*)
fürfirst-second
verwendet wird, kannsecond
im Ziel mit:paramName
verwendet werden.
Header mit basePath-Unterstützung
Bei Verwendung von basePath
-Unterstützung mit Headern wird jede source
automatisch mit dem basePath
präfigiert, es sei denn, Sie fügen basePath: false
zum Header hinzu:
Header mit i18n-Unterstützung
Bei Verwendung der i18n
-Unterstützung werden bei Headern automatisch alle source
-Einträge mit den konfigurierten locales
versehen, es sei denn, Sie fügen locale: false
zum Header hinzu. Wenn locale: false
verwendet wird, müssen Sie die source
mit einem Gebietsschema versehen, damit sie korrekt zugeordnet wird.
Cache-Control
Next.js setzt den Cache-Control
-Header auf public, max-age=31536000, immutable
für wirklich unveränderliche Assets. Er kann nicht überschrieben werden. Diese unveränderlichen Dateien enthalten einen SHA-Hash im Dateinamen, sodass sie sicher unbegrenzt zwischengespeichert werden können. Beispielsweise Statische Bildimporte. Sie können für diese Assets keine Cache-Control
-Header in next.config.js
festlegen.
Sie können jedoch Cache-Control
-Header für andere Antworten oder Daten festlegen.
Weitere Informationen zum Caching mit dem App Router.
Optionen
CORS
Cross-Origin Resource Sharing (CORS) ist eine Sicherheitsfunktion, die es Ihnen ermöglicht zu steuern, welche Seiten auf Ihre Ressourcen zugreifen können. Sie können den Access-Control-Allow-Origin
-Header festlegen, um einem bestimmten Ursprung den Zugriff auf Ihre Route-Handler zu erlauben.
X-DNS-Prefetch-Control
Dieser Header steuert das DNS-Prefetching und ermöglicht Browsern, proaktiv Domainnamenauflösungen für externe Links, Bilder, CSS, JavaScript und mehr durchzuführen. Dieses Prefetching wird im Hintergrund ausgeführt, sodass die DNS wahrscheinlich aufgelöst ist, wenn die referenzierten Elemente benötigt werden. Dies reduziert die Latenz, wenn der Benutzer einen Link anklickt.
Strict-Transport-Security
Dieser Header informiert Browser, dass nur über HTTPS zugegriffen werden sollte, anstatt über HTTP. Mit der unten stehenden Konfiguration werden alle aktuellen und zukünftigen Subdomains für eine max-age
von 2 Jahren über HTTPS verwendet. Dies blockiert den Zugriff auf Seiten oder Subdomains, die nur über HTTP bereitgestellt werden können.
Wenn Sie auf Vercel bereitstellen, ist dieser Header nicht erforderlich, da er automatisch zu allen Bereitstellungen hinzugefügt wird, es sei denn, Sie deklarieren headers
in Ihrer next.config.js
.
X-Frame-Options
Dieser Header gibt an, ob die Website in einem iframe
angezeigt werden darf. Dies kann Clickjacking-Angriffe verhindern.
Dieser Header wurde durch die CSP-Option frame-ancestors
ersetzt, die in modernen Browsern besser unterstützt wird (weitere Konfigurationsdetails finden Sie unter Content Security Policy).
Permissions-Policy
Dieser Header ermöglicht es Ihnen, zu steuern, welche Features und APIs im Browser verwendet werden können. Er wurde zuvor Feature-Policy
genannt.
X-Content-Type-Options
Dieser Header verhindert, dass der Browser versucht, den Inhaltstyp zu erraten, wenn der Content-Type
-Header nicht explizit gesetzt ist. Dies kann XSS-Exploits für Websites verhindern, die es Benutzern ermöglichen, Dateien hochzuladen und zu teilen.
Beispielsweise ein Benutzer, der versucht, ein Bild herunterzuladen, aber es als ein anderer Content-Type
wie eine ausführbare Datei behandelt wird, was potenziell schädlich sein könnte. Dieser Header gilt auch für das Herunterladen von Browser-Erweiterungen. Der einzige gültige Wert für diesen Header ist nosniff
.
Referrer-Policy
Dieser Header steuert, wie viele Informationen der Browser beim Navigieren von der aktuellen Website (Herkunft) zu einer anderen einschließt.
Content-Security-Policy
Erfahren Sie mehr über das Hinzufügen einer Content-Sicherheitsrichtlinie zu Ihrer Anwendung.
Versionsverlauf
Version | Änderungen |
---|---|
v13.3.0 | missing hinzugefügt. |
v10.2.0 | has hinzugefügt. |
v9.5.0 | Header hinzugefügt. |