Liste der HTTP-Headerfelder
HTTP-Header-Felder (oft ungenau HTTP-Header) sind Bestandteile des Hypertext Transfer Protocol (HTTP)-Protokollheaders und übermitteln die für die Übertragung von Dateien über HTTP wichtigen Parameter und Argumente, z. B. gewünschte Sprache oder Zeichensatz sowie oft Informationen über den Client. Oft wird „HTTP-Header“ synonym genutzt, besitzt allerdings die Mehrdeutigkeit zwischen einem einzelnen Feld des Headerblocks und dem ganzen Headerblock. Hier wird für die Gesamtheit der Headerfelder der Begriff „Header“ und für eine einzelne Zeile im Header der Begriff „Headerfeld“ entsprechend RFC 2616 genutzt. Die einzelnen Felder im Header werden immer nach der Anfrage-(Request)-Zeile (z. B. GET /index.html HTTP/1.1) bzw. der Antwort-(Response)-Zeile (bei Erfolg HTTP/1.1 200 OK) übermittelt. Die Zeilen des Headers selbst sind Schlüssel-Wert-Paare, getrennt durch Doppelpunkte (z. B. Content-type: text/html). Die Namen sind durch verschiedene Standards fest spezifiziert. Die Zeilenenden werden durch die Zeichenkombination <CR><LF> (carriage return, line feed) markiert, das Ende des Headers wird durch eine Leerzeile signalisiert, was der Übermittlung von <CR><LF><CR><LF> gleicht. Die meisten Headerfelder werden durch RFCs der IETF standardisiert, z. B. der „Kern“ in RFC 2616 und Erweiterungen in RFC 4229. Die in diesen Spezifikationen getroffenen Standards müssen in allen HTTP-Implementierungen vorhanden sein. Zusätzlich können Hersteller oder Projekte Erweiterungen in ihre Software einbauen (für die dann allerdings keine Garantie besteht, dass sie von allen Implementierungen korrekt verstanden werden). Je nach Produkt kann auch der einzelne Anwender oder Administrator eigene Headerfelder definieren. Da im HTTP-Antwort-Header unter Umständen sicherheitskritische Informationen, wie beispielsweise der verwendete Webserver inklusive Version, ersichtlich sind (z. B. Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)), wird empfohlen, diese zu verbergen. Einsehen lassen sich die dauerhaften und provisorischen Headerfelder bei der Internet Assigned Numbers Authority (IANA).
HTTP-Header-Felder (oft ungenau HTTP-Header) sind Bestandteile des Hypertext Transfer Protocol (HTTP)-Protokollheaders und übermitteln die für die Übertragung von Dateien über HTTP wichtigen Parameter und Argumente, z. B. gewünschte Sprache oder Zeichensatz sowie oft Informationen über den Client. Oft wird „HTTP-Header“ synonym genutzt, besitzt allerdings die Mehrdeutigkeit zwischen einem einzelnen Feld des Headerblocks und dem ganzen Headerblock. Hier wird für die Gesamtheit der Headerfelder der Begriff „Header“ und für eine einzelne Zeile im Header der Begriff „Headerfeld“ entsprechend RFC 2616[1] genutzt.
Die einzelnen Felder im Header werden immer nach der Anfrage-(Request)-Zeile (z. B. GET /index.html HTTP/1.1) bzw. der Antwort-(Response)-Zeile (bei Erfolg HTTP/1.1 200 OK) übermittelt. Die Zeilen des Headers selbst sind Schlüssel-Wert-Paare, getrennt durch Doppelpunkte (z. B. Content-type: text/html). Die Namen sind durch verschiedene Standards fest spezifiziert. Die Zeilenenden werden durch die Zeichenkombination <CR><LF> (carriage return, line feed) markiert, das Ende des Headers wird durch eine Leerzeile signalisiert, was der Übermittlung von <CR><LF><CR><LF> gleicht.
Die meisten Headerfelder werden durch RFCs der IETF standardisiert, z. B. der „Kern“ in RFC 2616[1] und Erweiterungen in RFC 4229.[2] Die in diesen Spezifikationen getroffenen Standards müssen in allen HTTP-Implementierungen vorhanden sein. Zusätzlich können Hersteller oder Projekte Erweiterungen in ihre Software einbauen (für die dann allerdings keine Garantie besteht, dass sie von allen Implementierungen korrekt verstanden werden). Je nach Produkt kann auch der einzelne Anwender oder Administrator eigene Headerfelder definieren.[3][4]
Da im HTTP-Antwort-Header unter Umständen sicherheitskritische Informationen, wie beispielsweise der verwendete Webserver inklusive Version, ersichtlich sind (z. B. Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)), wird empfohlen, diese zu verbergen.[5][6]
Einsehen lassen sich die dauerhaften und provisorischen Headerfelder bei der Internet Assigned Numbers Authority (IANA).[7][8]
Anfrage-Headerfelder
[Bearbeiten | Quelltext bearbeiten]Die Anfrage-Felder kommen im Header der Anfrage eines HTTP-Clients (z. B. Browsers) an einen Webserver vor. Sie enthalten z. B. Informationen über die angeforderte Ressource und die vom Client angenommenen MIME-Typen.
Für exakte Nachforschungen sei die Lektüre von RFC 2616, Kapitel 14[9] empfohlen (Kapitelnummer in der zweiten Spalte der Tabelle).[1]
| Name des Felds | Kapitel in RFC 2616[1] | Beschreibung | Beispiel |
|---|---|---|---|
| Accept | 14.1 | Welche Inhaltstypen der Client verarbeiten kann. Ist es dem Server nicht möglich, einen Inhaltstyp bereitzustellen, der vom Client akzeptiert wird, kann er entweder den HTTP-Statuscode 406 Not acceptable senden oder einen beliebigen Inhaltstyp zum Kodieren der angeforderten Informationen verwenden.[10] Fehlt das Accept-Feld, so bedeutet dies, dass der Client alle Inhaltstypen akzeptiert. Kann der Server in diesem Beispiel den Inhalt der angeforderten Ressource sowohl als HTML als auch als Bild im GIF-Format an den Client senden, führt der Accept-Header der Anfrage dazu, dass als Inhaltstyp der Antwort HTML gewählt wird. |
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
|
| Accept-Charset | 14.2 | Welche Zeichensätze der Client anzeigen kann und somit empfangen möchte. Die passende Datei wird über Content Negotiation (z. B. bei Apache mod_negotiation) herausgesucht. | Accept-Charset: utf-8
|
| Accept-Encoding | 14.3 | Welche komprimierten Formate der Client unterstützt. Über Content Negotiation wird eine passend komprimierte Datei ausgeliefert. | Accept-Encoding: gzip,deflate
|
| Accept-Language | 14.4 | Welche Sprachen der Client akzeptiert. Falls der Server passend eingerichtet ist und die Sprachversionen vorhanden sind, wird über Content Negotiation die passende Datei ausgeliefert. | Accept-Language: en-US
|
| Authorization | 14.8 | Authentifizierungsdaten für HTTP-Authentifizierungsverfahren | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
|
| Cache-Control | 14.9 | Legt Optionen fest, denen durch alle Caching-Mechanismen entlang der Anfrage-/Antwort-Kette Folge geleistet werden muss. | Cache-Control: no-cache
|
| Connection | 14.10 | Steuert, was mit der Verbindung passiert, wenn die Anfrage abgeschlossen ist. | Connection: close
|
| Cookie | HTTP-Cookie, das zuvor vom Server mit Set-Cookie gesetzt wurde |
Cookie: $Version=1; Skin=new;
| |
| Content-Length | 14.13 | Länge des Bodys in Bytes | Content-Length: 348
|
| Content-MD5 | 14.15 | Eine Base64-codierte MD5-Checksumme des Bodys | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
|
| Content-Type | 14.17 | MIME-Typ des Bodys (hier genutzt für POST- und PUT-Operationen) | Content-Type: application/x-www-form-urlencoded
|
| Date | 14.18 | Datum und Zeit zum Sendezeitpunkt der Anfrage | Date: Tue, 15 Nov 1994 08:12:31 GMT
|
| Expect | 14.20 | Zeigt, welches Verhalten der Client vom Server erwartet. Falls der Server diesen Header nicht versteht oder das Verhalten nicht erfüllen kann, muss er den Code 417 Expectation Failed senden. Der Client sendet ein Expect: 100-continue, wenn er nur den Header, aber nicht den Body einer (sehr großen) Anfrage sendet und daraufhin den HTTP-Statuscode 100 Continue als Bestätigung erwartet, um eine evtl. sehr große Anfrage schicken zu können. Zweck ist hierbei, sicherzugehen, dass der Server die (sehr große) Anfrage annehmen wird. |
Expect: 100-continue
|
| Forwarded | RFC 7239[11] | Dient bei weiterleitenden Reverse Proxies (z. B. Lastverteiler) der Identifizierung des ursprünglich anfragenden Clients, des ursprünglich genutzten Protokolls sowie des ursprünglich angefragten Hosts und Ports, da ein Reverse Proxy diese Informationen funktionsbedingt verändert. | Forwarded: by="10.0.0.1"; for="192.168.0.1:4711"; proto=http; host="www.example.com:8080"
|
| From | 14.22 | E-Mail-Adresse des Nutzers, der die Anfrage stellte (heute unüblich). RFC 2616[1] sagt hierzu, dass der From: nicht ohne ausdrückliche Genehmigung des Nutzers gesendet werden darf. |
From: user@example.com
|
| Host | 14.23 | Domain-Name des Servers, zwingend vorgeschrieben seit HTTP/1.1 und nötig für namensbasierte Hosts. Bei Fehlen dieses Headers muss der Server nach Definition mit 400 Bad Request antworten. |
Host: en.wikipedia.org
|
| If-Match | 14.24 | Aktion nur durchführen, falls der gesendete Code mit dem auf dem Server vorhandenen Code übereinstimmt. | If-Match: "737060cd8c284d8af7ad3082f209582d"
|
| If-Modified-Since[12] | 14.25 | Erlaubt dem Server, den Statuscode 304 Not Modified zu senden, falls sich seit dem angegebenen Zeitpunkt nichts verändert hat. |
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
|
| If-None-Match | 14.26 | Erlaubt dem Server bei unverändertem Inhalt (verifiziert durch HTTP ETags) den Statuscode 304 Not Modified als Antwort. |
If-None-Match: "737060cd8c284d8af7ad3082f209582d"
|
| If-Range | 14.27 | Falls der Client einen Teil einer Datei vom Server im Cache liegen hat, die sich auf dem Server nicht verändert hat, nur den fehlenden Rest senden; ansonsten ganze Datei schicken. | If-Range: "737060cd8c284d8af7ad3082f209582d"
|
| If-Unmodified-Since | 14.28 | Nur dann die Seite senden, falls diese seit dem angegebenen Zeitpunkt nicht geändert wurde. Wurde die Seite geändert, so sendet der Server den Statuscode 412 Precondition Failed, bei unveränderter Seite unterscheidet sich die Antwort nicht von einer normalen Antwort und der Client erhält einen 2xx-Statuscode (Success). |
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
|
| Max-Forwards | 14.31 | Begrenzt die Anzahl der möglichen Weiterleitungen durch Proxys oder Gateways. Das Feld enthält die verbleibende Anzahl an Weiterleitungen, somit muss jeder Proxy diese Zahl dekrementieren. | Max-Forwards: 10
|
| Pragma | 14.32 | Optionen, die möglicherweise nur von einigen Implementationen verstanden werden und sich an alle Glieder in der Frage-Antwort-Kette richten. | Pragma: no-cache
|
| Proxy-Authorization[13] | 14.34 | Autorisierungsdaten für Proxys mit Autorisierungszwang | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
|
| Range | 14.35 | Bereich, den der Client vom Server anfordert (in diesem Beispiel nur die Bytes 500-999) | Range: bytes=500-999
|
| Referer[sic] | 14.36 | URI der verweisenden Seite (insb. bei Webbrowsern). Klickt man bspw. auf der Hauptseite der deutschsprachigen Wikipedia einen Link an, so sendet der Browser dem Server der aufgerufenen Seite das Headerfeld im Beispiel. | Referer: https://de.wikipedia.org/wiki/Wikipedia:Hauptseite
|
| TE | 14.39 | Welche Kompressionsformate der Client annehmen kann, möglich sind z. B. gzip oder deflate. „trailers“ gibt hier an, dass der Client das Feld „Trailer“ in den einzelnen Stücken beim Encoding-Modus „Chunked“ akzeptiert und auswertet. (Siehe hierzu Kapitel 3.6, 3.6.1, 14.39, 14.40 in RFC 2616[1]) | TE: trailers, deflate
|
| Transfer-Encoding | 14.41 | Die Transformationen, die angewendet wurden, um den Inhalt zum Server zu transportieren. Zurzeit sind folgende Methoden[14] definiert: chunked (aufgeteilt), compress (komprimiert), deflate (komprimiert), gzip (komprimiert), identity. | Transfer-Encoding: chunked
|
| Upgrade | 14.42 | Vorschlag an den Server, ein anderes Protokoll zu nutzen | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
|
| User-Agent | 14.43 | Der User-Agent-String des Clients. In ihm stehen Informationen über den Client, sodass z. B. ein serverseitiges Skript an verschiedene Browser angepasste Inhalte ausliefern kann (z. B. bei Downloadseiten, bei denen für Mac OS andere Links angeboten werden sollen als für Windows) | User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
|
| Via | 14.45 | Gibt dem Server Informationen über Proxys im Übertragungsweg. | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
|
| Warning | 14.46 | Allgemeine Warnungen über den Umgang mit dem Body oder den Body selbst. | Warning: 199 Miscellaneous warning
|
Antwort-Headerfelder
[Bearbeiten | Quelltext bearbeiten]| Headerfeld | Kapitel in RFC 2616[1] | Beschreibung | Beispiel |
|---|---|---|---|
| Accept-Ranges | 14.5 | Akzeptierte Einheiten für die Range-Angabe |
Accept-Ranges: bytes
|
| Age | 14.6 | Wie lange das Objekt im Proxy-Cache gelegen hat (in Sekunden). | Age: 12
|
| Allow | 14.7 | Erlaubte Aktionen für eine bestimmte Ressource. Muss u. a. bei einem Statuscode 405 Method Not Allowed mitgesendet werden. |
Allow: GET, HEAD
|
| Cache-Control | 14.9 | Teilt allen Caching-Mechanismen entlang der Abrufkette (z. B. Proxys) mit, ob und wie lange das Objekt gespeichert werden darf (in Sekunden). | Cache-Control: max-age=3600
|
| Connection | 14.10 | Bevorzugte Verbindungsarten | Connection: close
|
| Content-Encoding | 14.11 | Codierung des Inhalts | Content-Encoding: gzip
|
| Content-Language | 14.12 | Die Sprache, in der die Datei vorliegt (nur sinnvoll bei Content-Negotiation). Wird gesendet, falls der Server mittels Content Negotiation entweder eine Sprache erkannt und ausliefert oder wenn der Server anhand der Endung eine Sprache erkennt. | Content-Language: de
|
| Content-Length | 14.13 | Länge des Bodys in Bytes | Content-Length: 348
|
| Content-Location | 14.14 | Alternativer Name/Speicherplatz für das angeforderte Element. Wird mittels CN beispielsweise „foo.html“ angefordert, und der Server schickt aufgrund des Accept-language-Felds die deutsche Version, die eigentlich unter foo.html.de liegt, zurück, so steht hier der Name der Originaldatei. |
Content-Location: /foo.html.de
|
| Content-MD5 | 14.15 | Die Base64-codierte MD5-Checksumme des Bodys | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
|
| Content-Disposition | 19.5.11) | Zusätzliche Informationen zur Verarbeitung des Payloads. So kann beispielsweise eine Datei als Download markiert werden, sodass Browser nicht versuchen, sie selbst anzuzeigen, sondern einen Download-Dialog öffnen. | Content-Disposition: attachment; filename=fname.ext
|
| Content-Range | 14.16 | Welchen Bereich des Gesamtbodys der gesendete Inhalt abdeckt. | Content-Range: bytes 21010-47021/47022
|
| Content-Security-Policy | W3C CSP 1.0 | Sicherheitskonzept, um Cross-Site-Scripting (XSS) und ähnliche Angriffe abzuwehren. | Content-Security-Policy: default-src https://cdn.example.net; frame-src 'none'; object-src 'none'
|
| Content-Type | 14.17 | MIME-Typ der angeforderten Datei. Er kann nicht mit einer Charset-Angabe im HTML-Header überschrieben werden. | Content-Type: text/html; charset=utf-8
|
| Date | 14.18 | Zeitpunkt des Absendens | Date: Tue, 15 Nov 1994 08:12:31 GMT
|
| ETag | 14.19 | Eine bestimmte Version einer Datei, oft als Message Digest realisiert. | ETag: "737060cd8c284d8af7ad3082f209582d"
|
| Expires | 14.21 | Ab wann die Datei als veraltet angesehen werden kann. | Expires: Thu, 01 Dec 1994 16:00:00 GMT
|
| Last-Modified | 14.29 | Zeitpunkt der letzten Änderung an der Datei (als RFC 2822[15]). | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
|
| Link | RFC 5988 Abschn. 5[16] | Wird benutzt, um dem Client „verwandte“ Dateien oder Ressourcen mitzuteilen, z. B. einen RSS-Feed, einen Favicon, Copyright-Lizenzen etc. Dieses Header-Feld ist äquivalent zum <link />-Feld in (X)HTML.[16] |
Link: </feed>; rel="alternate"
|
| Location | 14.30 | Im Falle einer Umleitung (Status Code 3xx) die URL, zu der umgeleitet werden soll. Im Fall von 201 Created der Ort der angelegten Ressource. |
Location: https://www.w3.org/People.html
|
| P3P | – | Dieses Feld wird genutzt, um eine P3P-Datenschutz-Policy wie folgt mitzuteilen:P3P:CP="your_compact_policy". P3P setzte sich nicht richtig durch,[17] wird jedoch von einigen Browsern und Webseiten genutzt, um z. B. Cookie-Richtlinien durchzusetzen oder zu überprüfen. |
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
|
| Pragma | 14.32 | Implementierungsspezifische Optionen, die mehrere Stationen in der Request-Response-Kette beeinflussen können. | Pragma: no-cache
|
| Proxy-Authenticate | 14.33 | Ob und wie der Client sich beim Proxy authentifizieren muss. | Proxy-Authenticate: Basic
|
| Refresh | Proprietär | Anweisung an den Client, nach einer bestimmten Zeit (in Sekunden) die Seite zu aktualisieren oder weiterzuleiten. Dieses Headerfeld ist proprietär und kommt von Netscape, wird aber von den meisten Browsern unterstützt. | Refresh: 5; url=https://www.w3.org/People.html
|
| Retry-After | 14.37 | Falls eine Ressource zeitweise nicht verfügbar ist, teilt der Server in diesem Feld mit, wann sich ein neuer Versuch lohnt. | Retry-After: 120
|
| Server | 14.38 | Beschreibung der zugrundeliegenden Software, z B. der verwendete Webserver und das Betriebssystem (Pendant zum User-Agent) |
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
|
| Set-Cookie | – | HTTP-Cookie, das der Client setzen soll | Set-Cookie: UserID=FooBar; Max-Age=3600; Version=1
|
| Trailer | 14.40 | Namen der Headerfelder, die im Trailer der Antwort (bei Chunked-Encoding) enthalten sind. Eine Nachricht in Chunked-Encoding ist aufgeteilt in den Header (Kopf), den Rumpf (Body) und den Trailer, wobei der Rumpf aus Effizienzgründen in Teile (Chunks) aufgeteilt sein kann. Der Trailer kann dann (je nach Wert des TE-Feldes der Anfrage) Header-Informationen enthalten, deren Vorabberechnung der Effizienzsteigerung zuwiderläuft. | Trailer: Max-Forwards
|
| Transfer-Encoding | 14.41 | Methode, die genutzt wird, um den Inhalt zum Nutzer zu bringen. Zurzeit sind folgende Methoden[14] definiert: chunked (aufgeteilt), compress (komprimiert), deflate (komprimiert), gzip (komprimiert), identity. | Transfer-Encoding: chunked
|
| Vary | 14.44 | Zeigt Downstream-Proxys, wie sie anhand der Headerfelder zukünftige Anfragen behandeln sollen, also ob die gecachte Antwort genutzt werden kann oder eine neue Anfrage gestellt werden soll. | Vary: *
|
| Via | 14.45 | Informiert den Client, über welche Proxys die Antwort gesendet wurde. | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
|
| Warning | 14.46 | Eine allgemeine Warnung vor Problemen mit dem Body. | Warning: 199 Miscellaneous warning
|
| WWW-Authenticate | 14.47 | Authentifikationsmethode, die genutzt werden soll, um eine bestimmte Datei herunterzuladen (genauer definiert in RFC 2617[18]). | WWW-Authenticate: Basic
|
1) Nicht im offiziellen HTTP/1.1-Standard, da (Kapitel 15.5) eine Reihe von Sicherheitsbedenken geäußert wurden. Content-disposition ist in RFC 2183[19] genauer beschrieben.
Allgemeine, nicht-standardisierte Felder
[Bearbeiten | Quelltext bearbeiten]Anfrage-Felder
[Bearbeiten | Quelltext bearbeiten]Nicht-standardisierte Header tragen oft ein 'X-' am Anfang. Mit RFC 6648[20] gilt das Präfix X- als veraltet.
| Feldname | Beschreibung | Beispiel |
|---|---|---|
| X-Requested-With[21] | Oft genutzt bei Ajax. | X-Requested-With: XMLHttpRequest
|
| X-Do-Not-Track[22] | Befiehlt einer Website, das Verfolgen (Tracken) des Nutzers zu deaktivieren. Bis jetzt wird dieses Feld von den allermeisten Servern ignoriert. Dies könnte sich jedoch in der Zukunft noch ändern (siehe das Feld DNT). |
X-Do-Not-Track: 1
|
| DNT[23] oder Dnt | Befiehlt einer Website, den Nutzer nicht zu tracken. Dieses Feld ist Mozillas Version des X-Do-Not-Track-Feldes, wird aber auch von Safari 5, Internet Explorer 9 und Google Chrome (letzterer verwendet die Variante Dnt) unterstützt.[24] Am 7. März 2011 wurde ein Entwurf bei der IETF eingereicht.[25] |
DNT: 1
|
| X-Forwarded-For[26] | De-facto-Standard zur Identifizierung der ursprünglichen IP-Adresse eines Clients, der sich mit einem Webserver über einen HTTP-Proxy oder Lastverteiler verbindet. | X-Forwarded-For: client1, proxy1, proxy2
|
| X-Forwarded-Proto[27] | De-facto-Standard zur Identifizierung des ursprünglichen Protokolls der Verbindung mit einem zwischengeschalteten HTTP-Proxy oder Lastverteiler. | X-Forwarded-Proto: https
|
Antwort-Felder
[Bearbeiten | Quelltext bearbeiten]| Feldname | Beschreibung | Beispiel |
|---|---|---|
| X-Frame-Options[28] | Clickjacking-Schutz: „DENY“ – kein Rendering in einem Frame; „SAMEORIGIN“ – Nur dann kein Rendering, falls die Herkunft falsch ist. | X-Frame-Options: DENY
|
| X-XSS-Protection[29] | Filter für Cross-Site-Scripting (XSS) | X-XSS-Protection: 1; mode=block
|
| X-Content-Type-Options[30] | Der einzige definierte Wert „nosniff“ untersagt dem Internet Explorer, durch MIME-Sniffing einen anderen als den deklarierten Inhaltstyp zu bestimmen und anzuwenden. | X-Content-Type-Options: nosniff
|
| X-Powered-By[31] | Auf welcher Technik (ASP.NET, PHP, JBoss u. a.) die Webapplikation basiert (Details zur Version finden sich oft in X-Runtime, X-Version, oder X-AspNet-Version) |
X-Powered-By: PHP/5.3.8
|
| X-UA-Compatible[32] | Empfiehlt Render-Engines (oft ein abwärtskompatibler Modus), um den Inhalt anzuzeigen. Auch genutzt, um den Chrome Frame im Internet Explorer zu aktivieren. | X-UA-Compatible: IE=EmulateIE7X-UA-Compatible: IE=edgeX-UA-Compatible: Chrome=1
|
| X-Robots-Tag[33] | Legt für Webcrawler fest, welche Inhalte indexiert werden dürfen. | X-Robots-Tag: noarchiveX-Robots-Tag: unavailable_after: 25 Jun 2010 15:00:00 PSTX-Robots-Tag: googlebot: nofollow
|
| Referrer-Policy[34] | Kontrolliert, ob der Browser den Referrer an die Ziel-Webseite übertragen soll. | Referrer-Policy: no-referrer
|
Siehe auch
[Bearbeiten | Quelltext bearbeiten]Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ a b c d e f g RFC: – HTTP 1.1. 1999 (englisch).
- ↑ RFC: – HTTP Header Field Registrations. Dezember 2005 (englisch).
- ↑ Anleitung, um mit Apache2 eigene Headerfelder zu definieren ( vom 2. April 2015 im Internet Archive)
- ↑ Dokumentation der Direktive
header. httpd.apache.org - ↑ Ubuntu: Apache-Informationen „verstecken“. In: Johann.gr. 23. Dezember 2015, abgerufen am 20. Juni 2016 (englisch).
- ↑ How to hide Nginx version – Nginx Tips. In: ScaleScale.com. Abgerufen am 20. Juni 2016 (amerikanisches Englisch).
- ↑ Permanent Message Header Field Names. iana.org, 11. Juli 2019, abgerufen am 18. Juli 2019 (englisch).
- ↑ Provisional Message Header Field Names. iana.org, abgerufen am 18. Juli 2019 (englisch).
- ↑ RFC: – HTTP 1.1. 1999, Abschnitt 14 (englisch).
- ↑ RFC: Abschnitt 10.4.7 (englisch).
- ↑ RFC: – Forwarded HTTP Extension. Juni 2014 (englisch).
- ↑ If-Modified-Since – HTTP. MDN, 10. April 2023, abgerufen am 18. Juni 2023 (amerikanisches Englisch).
- ↑ Proxy-Authorization – HTTP. MDN, 10. April 2023, abgerufen am 5. Juli 2023 (amerikanisches Englisch).
- ↑ a b HTTP Parameters. iana.org
- ↑ RFC: – Internet Message Format. April 2001 (englisch).
- ↑ a b RFC: – Web Linking. Oktober 2010, Abschnitt 5 (englisch).
- ↑ P3P Work Suspended. W3C.
- ↑ RFC: – HTTP Authentication: Basic and Digest Access Authentication. Juni 1999 (englisch).
- ↑ RFC: – Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field. August 1997 (englisch).
- ↑ RFC: – Deprecating the “X-” Prefix and Similar Constructs in Application Protocols. Juni 2012 (englisch).
- ↑ docs.djangoproject.com ( vom 5. Oktober 2011 im Internet Archive)
- ↑ hackademix.net
- ↑ blog.sidstamm.com
- ↑ blogs.msdn.com
- ↑ Do Not Track: A Universal Third-Party Web Tracking Opt Out. IETF.
- ↑ Amos Jeffries: SquidFaq/ConfiguringSquid – Squid Web Proxy Wiki. 2. Juli 2010, abgerufen am 10. September 2009 (englisch).
- ↑ Dave Steinberg: How do I adjust my SSL site to work with GeekISP's loadbalancer? 10. April 2007, archiviert vom (nicht mehr online verfügbar) am 22. Mai 2011; abgerufen am 8. Januar 2025 (englisch).
- ↑ blogs.msdn.com
- ↑ Eric Lawrence: IE8 Security Part IV: The XSS Filter. 2. Juli 2008, abgerufen am 30. September 2010 (englisch).
- ↑ Eric Lawrence: IE8 Security Part VI: Beta 2 Update. 3. September 2008, abgerufen am 28. September 2010 (englisch).
- ↑ Why does ASP.NET framework add the 'X-Powered-By:ASP.NET' HTTP Header in responses? - Stack Overflow. Abgerufen am 30. September 2010 (englisch).
- ↑ Definiere Dokument Kompatibilität: Spezifiziere Dokument Kompatibilität Modus. 1. April 2011, abgerufen am 24. Januar 2012 (englisch).
- ↑ developers.google.com vom 18. September 2013.
- ↑ Scott Helme: A new security header: Referrer Policy. Abgerufen am 11. Oktober 2018 (englisch).