HTTP Header (Kopfzeilen) erlauben es dem Client und Server zusätzliche Informationen an eine Anfrage oder eine Antwort zu übergeben. Ein HTTP Header besteht aus seinem Namen (Groß-/Kleinschreibung unwichtig), gefolgt von einem Doppelpunkt ':' und dem Wert (ohne Zeilenumbrüche). Führender Leerraum vor dem Wert wird ignoriert.

Benutzerdefinierte, proprietäre Header können mit einem 'X-' Präfix hinzugefügt werden, diese Konvention wurde jedoch im Juni 2012 missbilligt, da es Unannehmlichkeiten verursachte, als nicht standardisierte Felder in RFC 6648 standardisiert wurden; andere sind im IANA Register aufgeführt, dessen ursprünglicher Inhalt in RFC 4229 definiert wurde. Die IANA pflegt auch ein Register mit Vorschlägen für neue HTTP Header.

Header können gemäß ihres Kontexts gruppiert werden:

  • General header: Header die sowohl für Anfragen als auch für Antworten zutreffen, jedoch keinen Bezug zu den Daten haben, die eventuell im Body übertragen werden.
  • Request header: Header die weitere Informationen über die angeforderte Ressource oder den Client selbst enthalten.
  • Response header: Header mit weiteren Informationen zur Antwort, wie etwa ihres Orts oder den Server selbst (Name und Version etc.)
  • Entity header: Header die weitere Informationen über den Body der Entität enthalten, wie etwa der Inhaltslänge oder ihren MIME-Type.

Header können auch danach gruppiert werden, wie Proxys sie verarbeiten:

End-to-end Header
Diese Header müssen an den endgültigen Empfänger der Nachricht übermittelt werden, d. h. den Server für eine Anfrage oder den Client für eine Antwort. Zwischen-Proxys müssen unmodifizierte End-to-end-Header erneut übertragen und zwischenspeichern.
Hop-by-hop Header
Diese Header sind nur für eine einzelne Verbindung auf Transportebene von Bedeutung und dürfen nicht von Proxys erneut übertragen oder zwischengespeichert werden. Solche Header sind: Connection, Keep-Alive, ProxyAuthenticate, Proxy-Authorization, TE, Trailer, Transfer-Encoding und Upgrade. Beachten Sie, dass nur Hop-by-hop Header mit dem allgemeinen Header Connection festgelegt werden können.

In der folgenden Liste werden die HTTP Header nach ihrer Verwendungskategorie zusammengefasst. Eine alphabetische Liste finden Sie in der Navigation auf der linken Seite.

Authentifizierung

WWW-Authenticate
Definiert die Authentifizierungsmethode, die verwendet werden soll, um Zugriff auf eine Ressource zu erhalten.
Authorization
Enthält die Anmeldeinformationen zum Authentifizieren eines Benutzer-Agenten an einem Server.
Proxy-Authenticate
Definiert die Authentifizierungsmethode, die verwendet werden soll, um Zugriff auf eine Ressource hinter einem Proxyserver zu erhalten.
Proxy-Authorization
Enthält die Anmeldeinformationen zum Authentifizieren eines Benutzer-Agenten an einem Proxyserver.

Caching

Age
Die Zeit in Sekunden, die sich das Objekt in einem Proxy-Cache befunden hat.
Cache-Control
Gibt Anweisungen für Cache-Mechanismen in Anfragen und Antworten an.
Clear-Site-Data
Löscht Browsing-Daten (z. B. Cookies, Storage, Cache), die der anfragenden Website zugeordnet sind.
Expires
Das Datum und die Uhrzeit, nach der die Antwort als veraltet gilt.
Pragma
Implementierungsspezifischer Header, der entlang der Anfrage-Antwort-Kette verschiedene Auswirkungen haben kann. Wird für die Abwärtskompatibilität mit HTTP/1.0 Caches verwendet, bei denen der Cache-Control-Header noch nicht vorhanden ist.
Warning
Ein allgemeines Warnfeld, das Informationen zu möglichen Problemen enthält.

Client Hints

HTTP Client Hints befinden sich noch in der Entwicklung. Dokumentation hierzu befindet sich auf der Webseite der HTTP Working Group.

Accept-CH
Server können Unterstützung für Clienthinweise unter Verwendung des Headerfelds Accept-CH oder eines entsprechenden HTML <meta> Element mit dem Attribut http-equiv attribute ([HTML5]) ankündigen.
Accept-CH-Lifetime
Server können den Client auffordern, sich an die vom Client für einen bestimmten Zeitraum unterstützten Client Hints zu erinnern, um die Zustellung von Client hints für nachfolgende Anfragen an den Ursprung des Servers zu ermöglichen ([RFC6454]).
Early-Data
Gibt an, dass die Anforderung in frühen Daten übermittelt wurde.
Content-DPR
Das Content-DPR Antwort Header-Feld ist eine Zahl, die das Verhältnis zwischen physischen Pixeln und CSS Pixeln des ausgewählten Bilds als Antwort angibt.
DPR
Das DPR Anfrage-Header-Feld ist eine Zahl, die das aktuelle Geräte-Pixelverhältnis (Device Pixel Ratio (DPR)) des Clients angibt. Hierbei handelt es sich um das Verhältnis der physischen Pixel zu CSS Pixeln (Abschnitt 5.2 von [CSSVAL]) des Layout Viewport (Abschnitt 9.1.1 von [CSS2]) auf dem Gerät.
Save-Data
Das SaveData [CLIENT-HINTS] Anfrage-Header-Feld besteht aus einem oder mehreren Token, die die Präferenz des Benutzer-Agenten für eine reduzierte Datennutzung angeben.
Viewport-Width

Das Viewport-Width Anfrage-Header-Feld ist eine Zahl, die die Breite des Layout Viewport in CSS Pixeln angibt. Der gegebene CSS Pixel Wert ist eine Zahl, die auf die kleinste folgende Ganzzahl (d. h. den Höchstwert) gerundet wird.

Wenn Viewport-Width mehr als einmal in einer Nachricht vorkommt, dann überschreibt der letzte Wert alle vorherigen.

Width

Das Width Anfrage-Header-Feld ist eine Zahl, die die gewünschte Ressourcenbreite in physischen Pixeln angibt (d. h. eigentliche Größe eines Bildes). Der gegebene physikalische Pixel Wert ist eine Zahl, die auf die kleinste folgende Ganzzahl (d. h. den Höchstwert) gerundet ist.

Wenn die gewünschte Ressourcenbreite zum Zeitpunkt der Anforderung nicht bekannt ist oder die Ressource keine Anzeigebreite aufweist, kann das Header-Feld Width weggelassen werden. Wenn Width mehr als einmal in einer Nachricht vorkommt, dann überschreibt der letzte Wert alle vorherigen.

Accept-CH
Server können Support für Client Hints bekanntgeben, indem das Accept-CH Header-Feld oder das entsprechende HTML <meta> Element mit http-equiv Attribut benutzt wird ([HTML5]).
Accept-CH-Lifetime
Servers can ask the client to remember the set of Client Hints that the server supports for a specified period of time, to enable delivery of Client Hints on subsequent requests to the server’s origin ([RFC6454]).
Early-Data
Indicates that the request has been conveyed in early data.

Bedingungen

Last-Modified
Ein Validator mit dem letzten Änderungsdatum der Ressource, mit welchem mehrere Versionen derselben Ressource miteinander verglichen werden. Es ist weniger genau als ETag, aber in einigen Umgebungen einfacher zu berechnen. Bedingte Anforderungen, die If-Modified-Since und If-Unmodified-Since verwenden, verwenden diesen Wert, um das Verhalten der Anforderung zu ändern.
ETag
Ein Validator für eine eindeutige Zeichenfolge, die die Version der Ressource identifiziert. Bedingte Anforderungen, die If-Match und If-None-Match verwenden, nutzen diesen Wert um das Verhalten der Anfrage zu verändern.
If-Match
Knüpft die Anfrage an eine Bedingung und wendet die Methode nur dann an, wenn die gespeicherte Ressource einem der gegebenen ETags entspricht.
If-None-Match
Knüpft die Anfrage an eine Bedingung und wendet die Methode nur dann an, wenn die gespeicherte Ressource keinem der gegebenen ETags entspricht. Dies kann dazu benutzt werden, um Caches zu aktualisieren (für sichere Anfragen) oder um zu verhindern, eine neue Ressource hochzuladen, wenn bereits eine existiert.
If-Modified-Since
Knüpft die Anfrage an eine Bedingung und erwartet, dass die Entität nur dann übertragen wird, wenn sie nach einem gegebenem Datum modifiziert wurde. Dies kann dazu benutzt werden, nur dann Daten zu übertragen, wenn der Cache veraltet ist.
If-Unmodified-Since
Knüpft die Anfrage an eine Bedingung und erwartet, dass die Entität nur dann übertragen wird, wenn sie nach einem gegebenem Datum nicht modifiziert wurde. Dies kann dazu benutzt werden, um die Stimmigkeit eines neuen Fragments eines bestimmten Bereichs mit vorherigen zu gewährleisten oder ein optimistisches Parallelitätskontrollsystem beim Modifizieren existierender Dokumente zu implementieren.
Vary
Legt fest, wie zukünftige Anfrage Header abgeglichen werden sollen, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprungsserver anzufordern.

Verbindungsverwaltung

Connection
Steuert, ob die Netzwerkverbindung geöffnet bleiben soll, nachdem die aktuelle Transaktion beendet ist.
Keep-Alive
Steuert, wie lange eine dauerhafte Verbindung geöffnet bleiben soll.

Inhaltsverhandlung

Accept
Setzt den Server darüber in Kenntnis, welche Art Daten zurückgesendet werden können (als MIME-Type).
Accept-Charset
Setzt den Server darüber in Kenntnis, welchen Zeichensatz der Client versteht.
Accept-Encoding
Setzt den Server über den Kodierungs-Algorithmus in Kenntnis, üblicherweise ein Kompressionsalgorithmus, der bei Rücksendung einer Ressource benutzt werden kann.
Accept-Language
Setzt den Server über die Sprache in Kenntnis, in welcher er zurücksenden soll. Dies ist ein Hinweis und nicht zwangsweise unter vollständiger Kontrolle des Benutzers: der Server sollte stets darauf achten eine explizite Benutzerauswahl nicht zu überschreiben (etwa die ausgewählte Sprache einer Dropdown-Liste).

Steuerung

Expect
Gibt an, welchen Anforderungen der Server erfüllen muss, um die Anfrage ordnungsgemäß bearbeiten zu können.
Max-Forwards
Eine Ganzzahl, welche die maximal erlaubte Anzahl an Weiterleitungen festlegt. Bei jeder Weiterleitung durch ein Gateway oder einen Proxy wird der Wert um 1 reduziert. Erreicht er 0 bevor die Anfrage ihr Ziel erreicht wird diese verworfen.

Cookies

Cookie
Enthält gespeicherte HTTP Cookies, die zuvor vom Server mit dem Header Set-Cookie gesendet wurden.
Set-Cookie
Sendet Cookies vom Server an den Benutzer-Agenten.
Cookie2
Enthielt ein HTTP-Cookie, welches zuvor vom Server mit dem Header Set-Cookie2 gesendet wurde, gilt durch die Spezifikation jedoch mittlerweile als veraltet. Benutzen Sie stattdessen Cookie.
Set-Cookie2
Sendete Cookies vom Server an den Benutzer-Agenten, gilt durch die Spezifikation jedoch mittlerweile als veraltet. Benutzen Sie stattdessen Set-Cookie.

Cross-origin Resource Sharing (CORS)

Erfahren Sie hier mehr zu Cross-origin Resource Sharing (CORS).

Access-Control-Allow-Origin
Gibt an, ob die Antwort geteilt werden kann.
Access-Control-Allow-Credentials
Gibt an, ob die Antwort auf die Anfrage verfügbar gemacht werden kann, wenn das Kennzeichen für Anmeldedaten wahr ist.
Access-Control-Allow-Headers
Wird als Antwort auf eine Vor-Anfrage verwendet, um anzugeben, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden können.
Access-Control-Allow-Methods
Gibt die Methode(n) an, die beim Zugriff auf die Ressource als Antwort auf eine Vor-Anfrage zulässig sind.
Access-Control-Expose-Headers
Gibt an, welche Header als Teil der Antwort verfügbar gemacht werden können, indem ihre Namen aufgelistet werden.
Access-Control-Max-Age
Gibt an, wie lange die Ergebnisse einer Vor-Anfrage zwischengespeichert werden können.
Access-Control-Request-Headers
Wird verwendet, wenn eine Vor-Anfrage ausgegeben wird, um dem Server mitzuteilen, welche HTTP-Header bei der tatsächlichen Anforderung verwendet werden.
Access-Control-Request-Method
Wird bei der Ausgabe einer Vor-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Methode bei der tatsächlichen Anforderung verwendet wird.
Cross-Origin-Resource-Policy
Der Header Cross-Origin-Resource-Policy verhindert, dass andere Domänen die Ressourcen laden.
Origin
Gibt an, woher ein Abruf stammt.
Timing-Allow-Origin
Gibt die Ursprünge an, die Werte von Attributen anzeigen dürfen, die über Funktionen der Resource Timing API abgerufen werden, die andernfalls aufgrund von Ursprungsbeschränkungen als Null gemeldet werden.
X-Permitted-Cross-Domain-Policies
Gibt an, ob eine domänenübergreifende Richtliniendatei (XML) zulässig ist. In der Datei kann eine Richtlinie definiert werden, mit der Web-Clients wie Adobe Flash Player oder Adobe Acrobat (z. B. PDF) die Erlaubnis erteilt werden darf, Daten zwischen Domänen zu verarbeiten.

Do Not Track

DNT
Wird verwendet, um die Tracking-Einstellung des Benutzers auszudrücken.
Tk
Gibt den Tracking-Status an, der auf die entsprechende Anfrage angewendet wurde.

Downloads

Content-Disposition
Gibt an, ob die übertragene Ressource inline angezeigt (Standardverhalten, wenn der Header nicht vorhanden ist) oder als Download behandelt werden und der Browser einen "Speichern unter" Dialog anzeigen soll.

Informationen zum Nachrichtenrumpf (Body)

Content-Length
Gibt die Größe des Body der Entität in Oktetten (Anzahl an 8-Bit Bytes) an, die an den Empfänger gesendet werden.
Content-Type
Gibt den Inhaltstyp der Ressource an.
Content-Encoding
Gibt den Kompressionsalgortihmus an.
Content-Language
Beschreibt die Sprache(n), die für das Publikum bestimmt ist/sind, damit der Benutzer nach seiner bevorzugten Sprache unterscheiden kann.
Content-Location
Gibt einen alternativen Ort für die zurückgegebenen Daten an.

Proxys

Forwarded
Enthält Informationen Client zugewandten Seite von Proxyservern, die geändert oder verloren geht, wenn ein Proxy am Pfad der Anfrage beteiligt ist.
X-Forwarded-For
Gibt die ursprünglichen IP-Adressen eines Clients an, der über einen HTTP-Proxy oder einen Load Balancer eine Verbindung zu einem Webserver herstellt.
X-Forwarded-Host
Gibt den ursprünglichen Host an, den ein Client angefragt hat, um eine Verbindung zu Ihrem Proxy oder Load Balancer herzustellen.
X-Forwarded-Proto
Gibt das Protokoll (HTTP oder HTTPS) an, mit dem ein Client eine Verbindung zu Ihrem Proxy oder Load Balancer herstellt.
Via
Wird durch sowohl durch Vorwärts- als auch Rückwärtsproxys hinzugefügt und kann in den Anfrage Headern als auch den Antwort Headern erscheinen und gibt die Proxys an, über die die Nachricht versendet wurde.

Umleitungen

Location
Gibt die URL an, zu der eine Seite umgeleitet werden soll.

Anfragenkontext

From
Enthält eine Internet-E-Mail-Adresse für einen Benutzer, der den anfordernden Benutzer-Agenten steuert.
Host
Gibt den Domänennamen des Servers (für virtuelles Hosting) und (optional) die TCP-Portnummer an, auf welcher der Server lauscht.
Referer
Die Adresse der vorherigen Webseite, von der aus ein Link auf die aktuell angeforderte Seite folgt.
Referrer-Policy
Gibt an, welche Referrer-Informationen im Header Referer mit den gesendeten Anfragen enthalten sein sollen.
User-Agent
Enthält einen charakteristischen String, mit der die Netzwerkprotokollpartner den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfragenden Benutzer-Agenten bestimmen können. Siehe auch die Benutzer-Agenten-String Referenz von Firefox.

Antwortkontext

Allow
Listet die von einer Ressource unterstützten HTTP-Anfragemethoden auf.
Server
Enthält Informationen zu der Software, die der Ursprungsserver zur Bearbeitung der Anfrage verwendet.

Bereichsanfragen

Accept-Ranges
Gibt an, ob der Server Bereichsanfragen unterstützt und wenn ja, in welcher Einheit der Bereich ausgedrückt werden kann.
Range
Gibt den Teil eines Dokuments an, den der Server zurückgeben soll.
If-Range
Erzeugt eine bedingte Bereichanfrage, die nur erfüllt wird, wenn das gegebene ETag oder Datum mit der entfernten Ressource übereinstimmt. Kann verwendet werden, um das Herunterladen von zwei Bereichen von einer inkompatiblen Version der Ressource zu verhindern.
Content-Range
Gibt an, welchem Bereich des Body der gesendete Inhalt angehört.

Sicherheit

Content-Security-Policy (CSP)
Steuert Ressourcen, die der Benutzer-Agent für eine bestimmte Seite laden darf.
Content-Security-Policy-Report-Only
Webentwickler können mit Richtlinien experimentieren, indem sie ihre Auswirkungen überwachen, jedoch nicht durchsetzen. Berichte über Verstöße bestehen aus JSON-Dokumenten, die über eine HTTP POST Anfrage an die angegebene URI gesendet werden.
Expect-CT
Erlaubt es Websites, sich für die Berichterstellung und/oder Durchsetzung der Zertifikattransparenzanforderungen zu entscheiden. Dadurch wird verhindert, dass falsch ausgestellte Zertifikate für eine Seite unbemerkt bleiben. Wenn eine Seite den Expect-CT-Header aktiviert, fordert sie den Browser auf zu überprüfen, ob alle Zertifikate für diese Seite in öffentlichen CT-Protokollen angezeigt werden.
Feature-Policy
Stellt einen Mechanismus bereit, um die Verwendung von Browserfunktionen in seinem eigenen Frame und in eingebetteten iFrames zuzulassen und zu verbieten.
Public-Key-Pins (HPKP)
Ordnet einen bestimmten kryptografischen öffentlichen Schlüssel einem bestimmten Webserver zu, um das Risiko von Man-in-the-Middle-Angriffen mit gefälschten Zertifikaten zu verringern.
Public-Key-Pins-Report-Only
Sendet Berichte an die im Header angegebene URI zur Protokollierung, während Clients weiterhin eine Verbindung zum Server herstellen können, selbst wenn gegen das Pinning verstoßen wurde.
Strict-Transport-Security (HSTS)
Erzwingt die Kommunikation über HTTPS statt HTTP.
Upgrade-Insecure-Requests
Sendet ein Signal an den Server, dass der Client eine verschlüsselte und authentifizierte Antwort bevorzugt und dass die Anweisung upgrade-insecure-request erfolgreich verarbeitet werden kann.
X-Content-Type-Options
Deaktiviert das Erraten des MIME-Types durch den Browser und zwingt ihn den MIME-Type im Header Content-Type zu benutzen.
X-Download-Options
Gibt an, dass der Browser (Internet Explorer) nicht die Option zum "Öffnen" einer aus einer Anwendung heruntergeladenen Datei anzeigen sollte, um Phishing-Angriffe zu verhindern, da die Datei sonst im Kontext der Anwendung ausgeführt werden kann.
X-Frame-Options (XFO)
Gibt an, ob es einem Browser erlaubt wird eine Seite in einem <frame>, <iframe>, <embed> oder <object> Element darzustellen.
X-Powered-By
Kann durch Hosting-Umgebungen oder andere Frameworks festgelegt werden und enthält Informationen zu diesen, ohne der Anwendung oder ihren Besuchern einen Nutzen zu bieten. Heben Sie diesen Header auf, um zu verhindern mögliche Schwachstellen preiszugeben.
X-XSS-Protection
Aktiviert Seiten-übergreifende Skript-Filterung.

Vom Server gesendete Ereignisse

Last-Event-ID
...
NEL
Definiert einen Mechanismus, mit dem Entwickler eine Netzwerkfehler-Berichterstattungs-Richtlinie deklarieren können.
Ping-From
...
Ping-To
...
Report-To
Kann verwendet werden, um einen Server-Endpunkt anzugeben, an den der Browser Warnmeldungen und Fehlerberichte senden soll.

Übertragungskodierung

Transfer-Encoding
Gibt die Form der Kodierung an, die zum sicheren Übertragen der Entität an den Benutzer verwendet wird.
TE
Gibt die Übertragungskodierungen an, die der Benutzer-Agent akzeptiert.
Trailer
Ermöglicht dem Absender, am Ende einer Nachricht in mehreren Teilen zusätzliche Felder einzufügen.

WebSockets

Sec-WebSocket-Key
...
Sec-WebSocket-Extensions
...
Sec-WebSocket-Accept
...
Sec-WebSocket-Protocol
...
Sec-WebSocket-Version
...

Sonstiges

Accept-Push-Policy
Ein Client kann die gewünschte Push-Richtlinie für eine Anfrage ausdrücken, indem er ein Header-Feld Accept-Push-Policy mitsendet.
Accept-Signature
Ein Client kann das Header-Feld Accept-Signature senden, um anzugeben dass er beabsichtigt von verfügbaren Signaturen gebrauch zu machen und anzuzeigen, welche Art von Signaturen er unterstützt.
Alt-Svc
Kann verwendet werden, um alternative Wege aufzulisten, um diesen Dienst zu erreichen.
Date
Enthält das Datum und die Uhrzeit, zu dem die Nachricht erstellt wurde.
Large-Allocation
Setzt den Browser darüber in Kenntnis, dass die zu ladende Seite eine große Zuordnung durchführen möchte.
Link
Das Link Entitäten-Header-Feld bietet eine Möglichkeit, eine oder mehrere Links in HTTP-Headern zu serialisieren. Es entspricht semantisch dem HTML Element <link>.
Push-Policy
Eine Push-Policy definiert das Serververhalten bezüglich Push bei der Verarbeitung einer Anfrage.
Retry-After
Gibt an, wie lange der Benutzer-Agent warten soll, bevor eine Folgeanfrage gesendet wird.
Signature
Das Signature Header-Feld enthält eine Liste von Signaturen für einen Austausch, von welchem jeder Informationen darüber enthält, wie die Autorität dieser Signatur ermittelt und aktualisiert werden kann.
Signed-Headers
Das Signed-Headers Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in eine Signatur aufgenommen werden sollen.
Server-Timing
Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anfrage-Antwort-Zyklus.
SourceMap
Knüpft generierten Code an eine Source Map.
Upgrade
Das relevante RFC-Dokument für das Upgrade Header-Feld ist RFC 7230, Abschnitt 6.7. Der Standard legt Regeln für das Upgrade oder das Wechseln zu einem anderen Protokoll auf der aktuellen Client-, Server- und Transportprotokollverbindung fest. Mit diesem Header-Standard kann ein Client beispielsweise von HTTP 1.1 zu HTTP 2.0 wechseln, vorausgesetzt der Server beschließt, das Upgrade Header-Feld zu bestätigen und zu implementieren. Keine der Parteien muss die Bedingungen akzeptieren, die im Upgrade Header-Feld angegeben sind. Es kann in Client- und Server-Headern verwendet werden. Wenn das Upgrade Header-Feld angegeben ist, MUSS der Absender auch das Connection Header-Feld mit der angegebenen Upgrade Option senden. Einzelheiten zum Connection Header-Feld finden Sie in Abschnitt 6.1 des zuvor genannten RFC.
X-DNS-Prefetch-Control
Steuert das DNS-Prefetching, eine Funktion, mit der Browser proaktiv eine Namensauflösung sowohl für Links durchführen, denen der Benutzer folgen könnte, als auch URLs für Elemente, auf die im Dokument verwiesen wird, einschließlich Bilder, CSS, JavaScript, usw.
X-Firefox-Spdy
...
X-Pingback
...
X-Requested-With
...
X-Robots-Tag
Wird verwendet, um anzugeben, wie eine Webseite in öffentlichen Suchmaschinenergebnissen indiziert werden soll. Die Kopfzeile entspricht effektiv <meta name="robots" content="...">.
X-UA-Compatible
Wird von Internet Explorer verwendet, um zu signalisieren, welcher Dokumentmodus verwendet werden soll.

Mitwirken

Sie können helfen, indem Sie neue Einträge schreiben oder die vorhandenen verbessern.

Siehe auch

Schlagwörter des Dokuments und Mitwirkende

Mitwirkende an dieser Seite: King2500, mdnwebdocs-bot, SebinNyshkim, fl1p
Zuletzt aktualisiert von: King2500,