Archiv des Autors: admin

Modul Rewrite

So genannte ‚dirty links‘ werden so bezeichnet, weil Suchmaschinen damit meist wenig anfangen können und sich z. B. ein Link wie

http://php.nobs-nobody.de/show/home/

einfacher merken lässt als

http://php.nobs-nobody.de/index.php?action=show&page=home

Ein Problem bei vielen Webseiten ist der ‚trailing slash‘ (der slash am Ende der webseite), da Google z. B. unter

http://php.nobs-nobody.de

etwas anderes versteht als unter

http://php.nobs-nobody.de/

Ähnlich verhalten sich Google und Co. bei der Auswertung von Domains mit und ohne ‚www‘.

http://www.php.nobs-nobody.de/

ist nun mal etwas anderes als

http://php.nobs-nobody.de/

Die URI’s in unserem Beispiel so zu vereinfachen, benötigt jedoch ein klein wenig mehr Aufwand, da wir weniger im PHP, als viel mehr in die Server-Konfiguration eingreifen müssen. Das Ganze funktioniert aber nur, wenn unser Webserver ein Modul geladen hat das man
‚ mod_rewrite ‚ nennt. Die folgenden Beispiele konzentrieren sich dabei auf die Konfiguration eines Apache HTTP Servers der moderneren Version (2.x) – eine Anleitung für den IIS folgt später, bis dahin schaue man auf der Technet-Seite nach.

Canonical Page

Der erste Schitt ist sicher zu stellen, dass jede Seite über einen so genannten ‚canonical‘-Tag verfügt. Das erledigt man z. B. im Markup (HTML) mit einem Meta-Tag, der so aussieht:

<link rel="canonical" href="http://php.nobs-nobody.de/" />

Damit sagen wir jedem, der es wissen muss, dass die Inhalte der Seite ohne ‚www‘ und mit ‚trailing slash‘ aufgerufen werden. Jetzt müssen wir im zweiten Schritt nur noch jeden, der diesen ‚trailing slash‘ nicht bzw. das ‚www‘ verwendet, auf die Seite mit ‚trailing slash‘ und ohne ‚www‘ umleiten.
Dazu legen wir uns eine Datei namens ‚ .htaccess ‚ – der Punkt ist sehr wichtig, da er die Datei als versteckt markiert – in unserem Webseiten-Verzeichnis an und öffnen sie mit einem Texteditor.
Die Syntax in einer solchen Datei folgt festen Regeln und ist an die Sprache C angelehnt:

# Abfragestart, ob Modul geladen ist
<ifmodule [modul_datei]>
# Bedingung(en) für eine Überschreibungsregel
RewriteCond [Bedingung]
...
# Überschreibungsregel
RewiteRule [Regel]
# weitere Bedingungen und Regeln
...
# Abfrageende, ob Modul geladen ist
</ifmodule>

Als erstes wird abgefragt, ob ein entsprechendes Modul geladen ist: unser Server braucht ein geladenes Modul ‚mod_rewrite.c‘. Diese Abfrage muss immer in der Form
<ifmodule> … </ifmodule> stehen, da darin die Anweisungen nur für den Fall ausgeführt werden, dass das Modul geladen ist.
Eine oder mehrere Bedingungen werden für eine Regel festgelegt, wobei die Reihenfolge entscheident ist, da die Datei zeilenweise abgearbeitet wird.

Mit oder ohne ‚www‘

Schauen wir uns die wichtigen Zeilen für unser Beispiel mal genauer an:

# HTTP 301 Redirect 1. Variante ########################################
Redirect permanent http://www.php.nobs-nobody.de/ http://php.nobs-nobody.de/
# Modul mod_rewrite.c ##################################################
<ifmodule mod_rewrite.c>
RewriteEngine on
# HTTP 301 Redirect 2. Variante ########################################
  RewriteCond %{HTTP_HOST} !^php.nobs-nobody\.de$
  RewriteRule ^(.*)$ http://php.nobs-nobody.de/$1 [L,R=301]
</ifmodule>

Langsam zu mitdenken:

  • Umleitung 1. Variante: leite Requests an ‚ http://www.php.nobs-nobody.de/ ‚ nach ‚ http://php.nobs-nobody.de/ ‚ um –
    dies leitet aber tatsächlich nur von mit ‚www‘ auf ohne ‚www‘ um, hat aber den Vorteil, das es auch ohne Modul Rewrite funktioniert
  • Führe aus, wenn das Modul mod_rewrite.c gladen ist:
  • Schalte die Rewrite-Engine an
  • Umleitung 2. Variante:
  • Bedingung: wenn der angeforderte Host nicht php.nobs-nobody.de heißt (die .htaccess liegt in UNSEREM verzeichnis, also muss der Host so heißen) –
    %{HTTP_HOST} ist eine Severvariable, in der der vom Client angefragte Server
    (HTTP-Mime-Header-Feld ‚host‘) gespeichert ist,
    das ! bedeutet ’nicht‘,
    das ^ bedeutet ‚beginnt mit‘ und
    das $ bedeutet ‚hier ist Ende‘
  • Regel: dann leite den geforderten URI nach http://php.nobs-nobody.de/$1 um –
    das ^ bedeutet ‚beginnt mit‘,
    das (.*) ist ein Platzhalter,
    das $ bedeutet ‚hier ist Ende‘ und
    das $1 bedeutet der vorherigen Aufruf als Parameter ( ^(.*)$ )

Damit werden im Gegensatz zur ersten Variante so ziemlich alle Anfragen (wie eben auch www.php.nob-nobody.de) auf die „Default Domain“ php.nobs-nobody.de umgeleitet,
da das
[L,R=301]
bedeutet, dass hier erst einmal Schluss mit der Abarbeitung der .htaccess ist (L) und der Client mit einem 301-Status-Code (R=301 wie Redirect mit 301) auf die Adresse ohne ‚www‘ umgeleitet wird.

Trailing Slash


# Modul mod_rewrite.c ##################################################
<ifmodule mod_rewrite.c>
# HTTP 301 Redirect ####################################################
...
# ##### without trailing slash #########################################
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_URI} !(.*)/$
  RewriteRule ^(.*)$ $1/ [L,R=301]
</ifmodule>

Schön schrittweise (ohne die vorherigen Anweisungen):

  • 1. Bedingung: die Datei mit dem geforderten Dateinamen existiert nicht ( !-f ) –
    %{REQUEST_FILENAME} ist eine Severvariable, in der die vom Client angeforderte Datei gespeichert ist,
    das ! bedeutet ’nicht‘ und
    -f ist ein Schalter für ‚Datei existiert‘
  • 2. Bedingung: der URI (Webadresse) endet nicht mit einem Slash –
    %{REQUEST_URI} ist eine Severvariable, in der der vom Client angeforderte URI gespeichert ist,
    das ! bedeutet ’nicht‘,
    und (.*)/$ bedeutet: irgendein URI ( (.*) ) mit einem Slash (/) am Ende ($)

Damit werden alle Anfragen an

http://php.nobs-nobody.de oder http://php.nobs-nobody.de/show/home

nach

http://php.nobs-nobody.de/ oder http://php.nobs-nobody.de/show/home/

umgeleitet.

Schauen wir uns als nächstes die gesäuberten Links an:

Dirty Links


...
# Modul mod_rewrite.c ##################################################
<ifmodule mod_rewrite.c>
RewriteEngine on
# HTTP 301 Redirect ########################################
...
# ##### without trailing slash #################################
...
# ##### with trailing slash ####################################
  RewriteCond %{REQUEST_URI} (.*)/$
  RewriteRule ^(.*)/(.*)/ index.php?action=$1&page=$2
</ifmodule>

Überblicksweise (ohne die vorherigen Anweisungen):

  • Bedingung: wenn der angeforderte URI ( %{REQUEST_URI} ) ein Slash am Ende hat ( (.*)/$ )
  • Regel: dann mache aus dem Ausdruck
    <action>/<page>/ – ^(.*)/(.*)/
    den Ausdruck
    index.php?action=<action>&page=<page> – $1 ist der erste Platzhalter (.*) und $2 der zweite,
    wobei mit %{REQUEST_URI} hier alles hinter dem Host ‚php.nobs-nobody.de‘ in der Webadresse gemeint ist

Schaut Euch die Links auf der Schulungsseite php.nobs-nobdy.de an und Ihr werdet feststellen, dass sie alle in der Form

http://php.nobs-nobody.de/show/home/

notiert sind.

Damit kann Goole die Seite indizieren und den obigen Link kann man sich auch relativ gut merken.

HTTP-Header-Felder

HTTP-Header-Felder sind Bestandteile des Hypertext Transfer Protocol (HTTP)-Protokollheaders (RFC 2616) 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.

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 – auch \r\n) markiert, das Ende des Headers wird durch eine Leerzeile signalisiert, was der Übermittlung von <CR><LF><CR><LF> (oder \r\n\r\n) gleicht.

Die meisten Headerfelder werden durch RFC’s 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 zusätzliche Erweiterungen in ihre Software einbauen (für die dann allerdings keine Garantie besteht, dass sie von allen Implementierungen korrekt „verstanden“ werden). Je nach Anwendung kann auch der einzelne Administrator oder Entwickler eigene Headerfelder definieren.

Einsehen lassen sich die dauerhaften und provisorischen Headerfelder bei der (IANA.

Standardisierte Felder

Anfrage-Headerfelder

Die Anfrage-Felder kommen im Header der Anfrage eines Browsers an einen Webserver vor. Sie beinhalten z. B. Informationen über die angeforderte Datei und die vom Browser angenommenen Dateitypen.

Name des Felds Beschreibung Beispiel
Accept Welche Dateitypen der Browser verarbeiten kann. Laut RFC 2616, Abschnitt 14 muss der Server den HTTP-Statuscode 406 Not acceptable senden, falls er keinen der „akzeptablen“ Dateitypen bereithält und über Content Negotiation senden kann. Fehlt das Accept-Feld, so bedeutet dies, dass der Client alle Dateitypen akzeptiert. Bei diesem Beispiel wird der Server bei einer Anfrage „foo“ aus einer Auswahl von foo.html und foo.txt die Datei foo.html senden, da sie dem bevorzugten MIME-Typ entspricht (text/html). Accept: text/html, application/xhtml+xml, application/xml; q=0.9,*/*;q=0.8
Accept-Charset Welche Zeichensätze der Browser 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 Welche komprimierten Formate der Browser unterstützt. Über Content Negotiation wird eine passend komprimierte Datei ausgeliefert. Accept-Encoding: gzip,deflate
Accept-Language Welche Sprachen der Browser akzeptiert. Falls der Server passend eingerichtet ist und die Sprachversionen vorhanden sind, wird über Content Negotiation die passende Datei ausgeliefert. Accept-Language: de-DE
Authorization Authentifizierungsdaten für HTTP-Authentifizierungsverfahren Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control Wird genutzt, um Optionen festzulegen, denen durch alle Caching-Mechanismen entlang der Anfrage-/Antwort-Kette Folge geleistet werden muss. Cache-Control: no-cache
Connection Welchen Typ von Verbindung der Browser bevorzugt. Connection: close
Cookie ein HTTP-Cookie, das zuvor vom Server mit Set-Cookie gesetzt wurde Cookie: $Version=1; Skin=new;
Content-Length Länge des Bodys in Bytes Content-Length: 348
Content-MD5 Eine Base64-codierte MD5-Checksume des Bodys Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Type MIME-Typ des Bodys (hier genutzt für POST- und PUT-Operationen) Content-Type: application/x-www-form-urlencoded
Date Datum und Zeit zum Sendezeitpunkt der Anfrage Date: Tue, 15 Nov 1994 08:12:31 GMT
Expect 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
From E-mail-Adresse des Nutzers, der die Anfrage stellte (heute unüblich). RFC 2616 sagt hierzu, dass der From: nicht ohne ausdrückliche Genehmigung des Nutzers gesendet werden darf. From: nobs.nobody@gmx.de
Host 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: php.nobs-nobody.de
If-Match Aktion nur durchführen, falls der gesendete Code mit dem auf dem Server vorhandenen Code übereinstimmt. Wird z. B. für Aktionen genutzt, die nur dann ausgeführt werden sollen, falls sich etwas verändert hat. If-Match: „737060cd8c284d8af7ad3082f209582d“
If-Modified-Since 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 Erlaubt dem Server bei unverändertem Inhalt (verifiziert durch ETags) den Statuscode 304 Not Modified als Antwort, siehe HTTP ETag If-None-Match: „737060cd8c284d8af7ad3082f209582d“
If-Range 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 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 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 aktualisieren (dekrementieren) Max-Forwards: 10
Pragma Das Feld Pragma enthält 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 Im Feld Proxy-Authorization können Autorisierungsdaten für Proxys mit Autorisierungszwang eingebettet werden. Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range Enthält eine Bereichsangabe für den Bereich, den der Client vom Server anfordert (in diesem Beispiel nur die Bytes 500-999) Range: bytes=500-999
Referer Im Feld Referer ist der URI der verweisenden Seite enthalten. Klickt man also auf der Hauptseite der deutschsprachigen Wikipedia einen Link an, so sendet der Browser dem Server der aufgerufenen Seite ein Headerfeld wie im Beispiel. (Das Wort „Referer“ ist, sowohl im RFC als auch in den meisten Implementationen falsch geschrieben; richtig wäre „Referrer“ (von to refer, referred, referred) Referer: http://php.nobs-nobody.de/show/home/
TE Welche Formate der Client annehmen kann, möglich sind hier 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) TE: trailers, deflate
Upgrade Vorschlag an den Server, ein anderes Protokoll zu nutzen Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent 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 Microsoft Windows) User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Via Gibt dem Server Informationen über Proxys im Übertragungsweg. Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning Allgemeine Warnungen über den Umgang mit dem Body oder den Body selbst. Warning: 199 Miscellaneous warning

Antwort-Headerfelder

Headerfeld Beschreibung Beispiel
Accept-Ranges Welche Einheiten für Range-Angaben der Server akzeptiert. Accept-Ranges: bytes
Age Wie lange das Objekt im Proxy-Cache gelegen hat. Age: 12
Allow Erlaubte Aktionen für eine bestimmte Ressource. Muss u. a. mit einem 405 Method Not Allowed gesendet werden Allow: GET, HEAD
Cache-Control Teilt allen Caching-Mechanismen entlang der Abrufkette (z. B. Proxys) mit, ob und wie lange das Objekt gespeichert werden darf (in sec) Cache-Control: max-age=3600
Connection bevorzugte Verbindungsarten Connection: close
Content-Encoding Codierung des Inhalts Content-Encoding: gzip
Content-Language 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 Länge des Body in Bytes Content-Length: 348
Content-Location Alternativer Name/Speicherplatz für das angeforderte Element. Wird mittels CN beispielsweise „kontakt.html“ angefordert, und der Server schickt aufgrund des Accept-language-Felds die deutsche Version, die eigentlich unter kontakt.de.html liegt, zurück, so wird in Content-Location der Name der Originaldatei geschrieben Content-Location: /kontakt.de.html
Content-MD5 Die Base64-codierte MD5-Checksumme des Body Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Disposition Mit diesem nicht standardisierten und als gefährlich eingestuften Feld kann der Server für bestimmte MIME-Typen Downloadfenster erzeugen und einen Dateinamen vorschlagen. Content-Disposition: attachment; filename=fname.ext
Content-Range Welchen Bereich des Gesamtbodys der gesendete Inhalt abdeckt Content-Range: bytes 21010-47021/47022
Content-Security-Policy Sicherheitskonzept, um Cross-Site-Scripting (XSS) and ähnliche Angriffe abzuwehren Content-Security-Policy: default-src https://cdn.incapsula.com; frame-src ’none‘; object-src ’none‘
Content-Type Der 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 Zeitpunkt des Absendens Date: Tue, 15 Nov 1994 08:12:31 GMT
ETag Eine bestimmte Version einer Datei, oft als Message Digest realisiert ETag: „737060cd8c284d8af7ad3082f209582d“
Expires Ab wann die Datei als veraltet angesehen werden kann Expires: Thu, 01 Dec 1994 16:00:00 GMT
Last-Modified Zeitpunkt der letzten Änderung an der Datei (als RFC 2822) Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Link Wird benutzt, um dem Browser „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. Link: </feed>; rel=“alternate“
Location Oft genutzt, um Clients weiterzuleiten (mit einem 3xx-Code) Location: http://php.nobs-nobody.de/simple/
P3P Dieses Feld wird genutzt, um eine P3P-Datenschutz-Policy wie folgt mitzuteilen:P3P:CP=“your_compact_policy“. P3P setzte sich nicht richtig durch,[5] 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 Implementierungs-spezifische Optionen, die mehrere Stationen in der Request-Response-Kette beeinflussen können. Pragma: no-cache
Proxy-Authenticate Anweisung, ob und wie der Browser sich beim Proxy zu authentifizieren hat Proxy-Authenticate: Basic
Refresh Refresh wird genutzt, um nach einer bestimmten Zahl von Sekunden weiterzuleiten oder die Seite zu aktualisieren. Dieses Headerfeld ist proprietär und kommt von Netscape, wird aber von den meisten Browsern unterstützt Refresh: 5; url=http://html.nobs-nobody.de/home.html
Retry-After Falls eine Ressource zeitweise nicht verfügbar ist, so teilt der Server dem Client mit diesem Feld mit, wann sich ein neuer Versuch lohnt. Retry-After: 120
Server Serverkennung (so wie User-Agent für den Browser ist, ist Server für die Serversoftware) Server: Apache/2.2.24 (Unix)
Set-Cookie Ein Cookie Set-Cookie: UserID=nobs Max-Age=3600; Version=1
Trailer Das Trailer-Feld enthält die 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-Felders der Anfrage) Header-Informationen beinhalten, deren Vorabberechnung der Effizienzsteigerung zuwiderläuft. Trailer: Max-Forwards
Transfer-Encoding Die Methode, die genutzt wird, den Inhalt sicher zum Nutzer zu bringen. Zurzeit sind folgende Methoden definiert: chunked (aufgeteilt), compress (komprimiert), deflate (komprimiert), gzip (komprimiert), identity. Transfer-Encoding: chunked
Vary 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 Informiert den Client, über welche Proxys die Antwort gesendet wurde. Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning Eine allgemeine Warnung vor Problemen mit dem Body Warning: 199 Miscellaneous warning
WWW-Authenticate Definiert die Authentikationsmethode, die genutzt werden soll, um eine bestimmte Datei herunterzuladen (Genauer definiert in (RFC 2617) WWW-Authenticate: Basic

Allgemeine, nicht-standardisierte Felder

Anfrage-Felder

Nicht-standardisierte Header tragen oft ein ‚X-‚ am Anfang. Mit (RFC 6648 gilt der Präfix X- als veraltet.

Feldname Beschreibung Beispiel
X-Requested-With Oft genutzt bei Ajax. X-Requested-With: XMLHttpRequest
X-Do-Not-Track 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 auch das Feld ‚DNT‘ X-Do-Not-Track: 1
DNT Befiehlt einer Website, den Nutzer nicht zu tracken. Dieses Feld ist Mozillas Version des X-Do-Not-Track-Felds, wird aber auch von Safari 5 und Internet Explorer 9 unterstützt. Am 7. März 2011 wurde ein Entwurf bei der IETF eingereicht. DNT: 1
X-Forwarded-For ein Quasi-Standard für die Identifizierung der Original-IP-Adresse des Clients, der sich mit einem Webserver über einen HTTP-Proxy oder HTTP-Load-Balancer verbindet X-Forwarded-For: client1, proxy1, proxy2
X-Forwarded-Proto ein Quasi-Standard für die Identifizierung des Original-HTTP-Requests, wenn ein Reverse Proxy (Load Balancer) mit einem Webserver über HTTP kommuniziert X-Forwarded-Proto: https

Antwort-Felder

Feldname Beschreibung Beispiel
X-Frame-Options 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 Cross-Site-Scripting (XSS) Filter X-XSS-Protection: 1; mode=block
X-Content-Type-Options der einzige Wert, „nosniff“, soll den Internet Explorer vor MIME-Sniffing schützen X-Content-Type-Options: nosniff
X-Powered-By spezifiziert die Technologie (ASP.NET, PHP, JBoss, e.g.) über die eine Webanwendung arbeitet (Versionsdetails stehen oft in X-Runtime, X-Version oder X-AspNet-Version) X-Powered-By: PHP/5.2.17

Quelle: Wikipedia

HTTP-Status-Codes

Jede HTTP-Anfrage wird vom Server mit einem HTTP-Statuscode beantwortet. Er gibt zum Beispiel Informationen darüber, ob die Anfrage erfolgreich bearbeitet wurde, oder teilt dem Client, also etwa dem Browser, im Fehlerfall mit, wo (z. B. Umleitung) bzw. wie (z. B. mit Authentifizierung) er die gewünschten Informationen (wenn möglich) erhalten kann.

1xx Informationen

Die Bearbeitung der Anfrage dauert noch an.

100 Continue
Die laufende Anfrage an den Server wurde noch nicht zurückgewiesen. (Wird im Zusammenhang mit dem „Expect: 100-continue“-Header-Feld verwendet. Der Client kann nun mit der potentiell sehr großen Anfrage fortfahren.

101 Switching Protocols
Wird verwendet, wenn der Server eine Anfrage mit gesetztem „Upgrade“-Header-Feld empfangen hat und mit dem Wechsel zu einem anderen Protokoll einverstanden ist.

102 Processing
Wird verwendet, um ein Timeout zu vermeiden, während der Server eine zeitintensive Anfrage bearbeitet.

2xx Erfolgreiche Operation

Die Anfrage war erfolgreich.

200 OK
Die Anfrage wurde erfolgreich bearbeitet und das Ergebnis der Anfrage wird in der Antwort übertragen.

201 Created
Die Anfrage wurde erfolgreich bearbeitet. Die angeforderte Ressource wurde vor dem Senden der Antwort erstellt. Das „Location“-Header-Feld enthält eventuell die Adresse der erstellten Ressource.

202 Accepted
Die Anfrage wurde akzeptiert, wird aber zu einem späteren Zeitpunkt ausgeführt. Das Gelingen der Anfrage kann nicht garantiert werden.

203 Non-Authoritative Information
Die Anfrage wurde bearbeitet, das Ergebnis ist aber nicht unbedingt vollständig und aktuell.

204 No Content
Die Anfrage wurde erfolgreich durchgeführt, die Antwort enthält jedoch bewusst keine Daten.

205 Reset Content
Die Anfrage wurde erfolgreich durchgeführt; der Client soll das Dokument neu aufbauen und Formulareingaben zurücksetzen.

206 Partial Content
Der angeforderte Teil wurde erfolgreich übertragen (wird im Zusammenhang mit einem „Content-Range“-Header-Feld oder dem Content-Type multipart/byteranges verwendet). Kann einen Client über Teil-Downloads informieren (wird zum Beispiel von Wget genutzt, um den Downloadfortschritt zu überwachen oder einen Download in mehrere Streams aufzuteilen).

207 Multi-Status
Die Antwort enthält ein XML-Dokument, das mehrere Statuscodes zu unabhängig voneinander durchgeführten Operationen enthält.

208 Already Reported (WebDAV; RFC 5842)
Die Mitglieder einer WebDAV Bindung wurden bereits zuvor aufgezählt und sind in dieser Anfrage nicht mehr vorhanden.

226 IM Used (RFC 3229)
Der Server hat eine GET-Anforderung für die Ressource erfüllt, die Antwort ist eine Darstellung des Ergebnisses von einem oder mehreren Instanz-Manipulationen, bezogen auf die aktuelle Instanz.

3xx Umleitung

Um eine erfolgreiche Bearbeitung der Anfrage sicherzustellen, sind weitere Schritte seitens des Clients erforderlich.

300 Multiple Choices
Die angeforderte Ressource steht in verschiedenen Arten zur Verfügung. Die Antwort enthält eine Liste der verfügbaren Arten. Das „Location“-Header-Feld enthält eventuell die Adresse der vom Server bevorzugten Repräsentation.

301 Moved Permanently
Die angeforderte Ressource steht ab sofort unter der im „Location“-Header-Feld angegebenen Adresse bereit (auch Redirect genannt). Die alte Adresse ist nicht länger gültig.

302 Found
Die angeforderte Ressource steht vorübergehend unter der im „Location“-Header-Feld angegebenen Adresse bereit. Die alte Adresse bleibt gültig. Die Browser folgen meist mit einem GET, auch wenn der ursprüngliche Request ein POST war. Wird in HTTP/1.1 je nach Anwendungsfall durch die Statuscodes 303 bzw. 307 ersetzt. 302-Weiterleitung ist aufgrund eines Suchmaschinen-Fehlers, dem URL-Hijacking, in Kritik geraten.

303 See Other
Die Antwort auf die durchgeführte Anfrage lässt sich unter der im „Location“-Header-Feld angegebenen Adresse beziehen. Der Browser soll mit einem GET folgen, auch wenn der ursprüngliche Request ein POST war.

304 Not Modified
Der Inhalt der angeforderten Ressource hat sich seit der letzten Abfrage des Clients nicht verändert und wird deshalb nicht übertragen. Zu den Einzelheiten siehe Browser-Cache #Versionsvergleich.

305 Use Proxy
Die angeforderte Ressource ist nur über einen Proxy erreichbar. Das „Location“-Header-Feld enthält die Adresse des Proxy.

306 (reserviert)
306 wird nicht mehr verwendet, ist aber reserviert. Es wurde für „Switch Proxy“ verwendet.

307 Temporary Redirect
Die angeforderte Ressource steht vorübergehend unter der im „Location“-Header-Feld angegebenen Adresse bereit. Die alte Adresse bleibt gültig. Der Browser soll mit derselben Methode folgen wie beim ursprünglichen Request (d. h. einem POST folgt ein POST). Dies ist der wesentliche Unterschied zu 302/303.

308 Permanent Redirect
Experimentell eingeführt via RFC; die angeforderte Ressource steht ab sofort unter der im „Location“-Header-Feld angegebenen Adresse bereit, die alte Adresse ist nicht länger gültig. Der Browser soll mit derselben Methode folgen wie beim ursprünglichen Request (d. h. einem POST folgt ein POST). Dies ist der wesentliche Unterschied zu 302/303.[

4xx Client-Fehler

Bei der Bearbeitung der Anfrage ist ein Fehler aufgetreten, der im Verantwortungsbereich des Clients liegt.

400 Bad Request
Die Anfrage-Nachricht war fehlerhaft aufgebaut.

401 Unauthorized
Die Anfrage kann nicht ohne gültige Authentifizierung durchgeführt werden. Wie die Authentifizierung durchgeführt werden soll, wird im „WWW-Authenticate“-Header-Feld der Antwort übermittelt.

402 Payment Required
(reserviert)

403 Forbidden
Die Anfrage wurde mangels Berechtigung des Clients nicht durchgeführt. Diese Entscheidung wurde – anders als im Fall des Statuscodes 401 – unabhängig von Authentifizierungsinformationen getroffen, auch etwa wenn eine als HTTPS konfigurierte URL nur mit HTTP aufgerufen wurde.

404 Not Found
Die angeforderte Ressource wurde nicht gefunden. Dieser Statuscode kann ebenfalls verwendet werden, um eine Anfrage ohne näheren Grund abzuweisen. Links, welche auf solche Fehlerseiten verweisen, werden auch als Tote Links bezeichnet.

405 Method Not Allowed
Die Anfrage darf nur mit anderen HTTP-Methoden (zum Beispiel GET statt POST) gestellt werden. Gültige Methoden für die betreffende Ressource werden im „Allow“-Header-Feld der Antwort übermittelt.

406 Not Acceptable
Die angeforderte Ressource steht nicht in der gewünschten Form zur Verfügung. Gültige „Content-Type“-Werte können in der Antwort übermittelt werden.

407 Proxy Authentication Required
Analog zum Statuscode 401 ist hier zunächst eine Authentifizierung des Clients gegenüber dem verwendeten Proxy erforderlich. Wie die Authentifizierung durchgeführt werden soll, wird im „Proxy-Authenticate“-Header-Feld der Antwort übermittelt.

408 Request Time-out
Innerhalb der vom Server erlaubten Zeitspanne wurde keine vollständige Anfrage des Clients empfangen.

409 Conflict
Die Anfrage wurde unter falschen Annahmen gestellt. Im Falle einer PUT-Anfrage kann dies zum Beispiel auf eine zwischenzeitliche Veränderung der Ressource durch Dritte zurückgehen.

410 Gone
Die angeforderte Ressource wird nicht länger bereitgestellt und wurde dauerhaft entfernt.

411 Length Required
Die Anfrage kann ohne ein „Content-Length“-Header-Feld nicht bearbeitet werden.

412 Precondition Failed
Eine in der Anfrage übertragene Voraussetzung, zum Beispiel in Form eines „If-Match“-Header-Felds, traf nicht zu.

413 Request Entity Too Large
Die gestellte Anfrage war zu groß, um vom Server bearbeitet werden zu können. Ein „Retry-After“-Header-Feld in der Antwort kann den Client darauf hinweisen, dass die Anfrage eventuell zu einem späteren Zeitpunkt bearbeitet werden könnte.

414 Request-URL Too Long
Die URL der Anfrage war zu lang. Ursache ist oft eine Endlosschleife aus Redirects.

415 Unsupported Media Type
Der Inhalt der Anfrage wurde mit ungültigem oder nicht erlaubtem Medientyp übermittelt.

416 Requested range not satisfiable
Der angeforderte Teil einer Ressource war ungültig oder steht auf dem Server nicht zur Verfügung.

417 Expectation Failed
Verwendet im Zusammenhang mit einem „Expect“-Header-Feld. Das im „Expect“-Header-Feld geforderte Verhalten des Servers kann nicht erfüllt werden.

418 I’m a teapot
Dieser Code ist als Aprilscherz der IETF zu verstehen, welcher näher unter RFC 2324, Hyper Text Coffee Pot Control Protocol, beschrieben ist. Innerhalb eines scherzhaften Protokolls zum Kaffeekochen zeigt er an, dass fälschlicherweise eine Teekanne anstatt einer Kaffeekanne verwendet wurde. Dieser Statuscode ist allerdings kein Bestandteil von HTTP, sondern lediglich von HTCPCP[5] (Hyper Text Coffee Pot Control Protocol). Trotzdem ist dieser Scherz-Statuscode auf einigen Webseiten zu finden, real wird aber der Statuscode 200 gesendet.[6]

420 Policy Not Fulfilled
In W3C PEP (Working Draft 21. November 1997)[7] wird dieser Code vorgeschlagen, um mitzuteilen, dass eine Bedingung nicht erfüllt wurde.

421 There are too many connections from your internet address
Verwendet, wenn die Verbindungshöchstzahl überschritten wird. Ursprünglich wurde dieser Code in W3C PEP (Working Draft 21. November 1997)[7] vorgeschlagen, um auf den Fehler „Bad Mapping“ hinzuweisen.

422 Unprocessable Entity
Verwendet, wenn weder die Rückgabe von Statuscode 415 noch 400 gerechtfertigt wäre, eine Verarbeitung der Anfrage jedoch zum Beispiel wegen semantischer Fehler abgelehnt wird.

423 Locked
Die angeforderte Ressource ist zurzeit gesperrt.

424 Failed Dependency
Die Anfrage konnte nicht durchgeführt werden, weil sie das Gelingen einer vorherigen Anfrage voraussetzt.

425 Unordered Collection
In den Entwürfen von WebDav Advanced Collections definiert, aber nicht im „Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol“.

426 Upgrade Required
Der Client sollte auf Transport Layer Security (TLS/1.0) umschalten.

429 Too Many Requests
Der Client hat zu viele Anfragen in einem bestimmten Zeitraum gesendet.

Die Codes zwischen 430 und 499 sind nicht standardisiert und gehören zu proprietärer Software. Diese Codes können von anderen Browsern nur als allgemeiner unbekannter Fehler dem Benutzer angezeigt werden; nicht aber eine Übersetzung und Hinweise zum weiteren Vorgehen. Teilweise können die Server den Begleitumständen der Anfrage bereits entnehmen, dass es sich um die zugehörige Spezialsoftware handelt, und geben nur dann die privaten Codes zurück. Einige Beispiele sind nachstehend aufgelistet.

444 No Response
In Nginx-Logs verwendet, um anzuzeigen, dass der Server keine Informationen zum Client zurückgesendet und die Verbindung geschlossen hat.

449 The request should be retried after doing the appropriate action
Genutzt in Antworten von Microsoft Exchange Server.

451 Unavailable For Legal Reasons
Vom Google-Mitarbeiter Tim Bray vorgeschlagener Statuscode. Dieser Code soll darauf hinweisen, dass die angeforderte Ressource aufgrund von gesetzlichen Bestimmungen (Copyrighteinschränkungen, Zensur etc., eventuell beschränkt auf ein bestimmtes Land) nicht verfügbar ist.

5xx Server-Fehler

Es ist ein Fehler aufgetreten, dessen Ursache beim Server liegt.

500 Internal Server Error
Dies ist ein „Sammel-Statuscode“ für unerwartete Serverfehler.

501 Not Implemented
Die Funktionalität, um die Anfrage zu bearbeiten, wird von diesem Server nicht bereitgestellt. Ursache ist zum Beispiel eine unbekannte oder nicht unterstützte HTTP-Methode.

502 Bad Gateway
Der Server konnte seine Funktion als Gateway oder Proxy nicht erfüllen, weil er seinerseits eine ungültige Antwort erhalten hat.

503 Service Unavailable
Der Server steht temporär nicht zur Verfügung, zum Beispiel wegen Überlastung oder Wartungsarbeiten. Ein „Retry-After“-Header-Feld in der Antwort kann den Client auf einen Zeitpunkt hinweisen, zu dem die Anfrage eventuell bearbeitet werden könnte.

504 Gateway Time-out
Der Server konnte seine Funktion als Gateway oder Proxy nicht erfüllen, weil er innerhalb einer festgelegten Zeitspanne keine Antwort von seinerseits benutzten Servern oder Diensten erhalten hat.

505 HTTP Version not supported
Die benutzte HTTP-Version (gemeint ist die Zahl vor dem Komma) wird vom Server nicht unterstützt oder abgelehnt.

506 Variant Also Negotiates
Die Inhaltsvereinbarung der Anfrage ergibt einen Zirkelbezug.

507 Insufficient Storage
Die Anfrage konnte nicht bearbeitet werden, weil der Speicherplatz des Servers dazu zurzeit nicht mehr ausreicht.

509 Bandwidth Limit Exceeded
Die Anfrage wurde verworfen, weil sonst die verfügbare Bandbreite überschritten würde (inoffizielle Erweiterung einiger Server).

510 Not Extended
Die Anfrage enthält nicht alle Informationen, die die angefragte Server-Extension zwingend erwartet.

9xx Proprietäre Statuscodes, Netzwerkefehler

Neben den in RFC standardisierten Statuscodes gibt es noch weitere proprietäre Codes, die unter bestimmten Umständen eintreten. Der Fehler wird vom Netzwerk verursacht, nicht vom anfragenden Gerät. Der Client bzw. der Nutzer sollte dann seine Anfrage noch einmal stellen.

900–905 und 907
Beim Erhalt der Anfrage des Clients ist ein Fehler aufgetreten.

906
Bei der Übermittlung der Anfrage vom Client zum Remote-Server ist ein Fehler aufgetreten.

950
Bei der Interpretation einer Administrator-Anfrage des Nutzers ist ein Fehler aufgetreten.

Quelle: Wikipedia

HTTP-Request-Methoden

Im Folgenden, die wichtigsten Methoden, die ein HTTP-Client für Anfragen an Webserver verwenden kann:

GET
ist die gebräuchlichste Methode. Mit ihr wird eine Ressource (z. B. eine Datei) unter Angabe eines URI vom Server angefordert. Die Länge des URIs ist je nach eingesetztem Server begrenzt und sollte aus Gründen der Abwärtskompatibilität nicht länger als 255 Bytes sein. (siehe unten)

POST schickt nahezu unbegrenzte Mengen an Daten zur weiteren Verarbeitung zum Server, diese werden als Inhalt der Nachricht übertragen und können beispielsweise aus Name-Wert-Paaren bestehen, die aus einem HTML-Formular stammen.
Es können so neue Ressourcen auf dem Server entstehen oder bestehende modifiziert werden. POST-Daten werden im Allgemeinen nicht von Caches zwischengespeichert. Zusätzlich können bei dieser Art der Übermittlung auch Daten wie in der GET-Methode an den URI gehängt werden. (siehe unten)

HEAD weist den Server an, nur den HTTP-Header (der gleiche wie bei GET), aber keinen eigentlichen Inhalt (Body) zu senden. So kann zum Beispiel schnell die Gültigkeit einer Datei im Browsercache geprüft werden.

PUT dient dazu eine Ressource (z. B. eine Datei) unter Angabe des Ziel-URI’s auf einen Webserver hochzuladen, ist heute aber kaum implementiert.

DELETE löscht die angegebene Ressource auf dem Server. Heute ist das, ebenso wie PUT, kaum implementiert bzw. in der Standardkonfiguration von Webservern abgeschaltet.

Beide Methoden erlangen z. B. mit der HTTP-Erweiterung WebDAV eine neue Bedeutung.

TRACE liefert die Anfrage so zurück, wie der Server sie empfangen hat. So kann überprüft werden, ob und wie die Anfrage auf dem Weg zum Server verändert worden ist, was vor allem für das Debugging von Verbindungen sinnvoll ist.

OPTIONS liefert eine Liste der vom Server unterstützen Methoden und Features.

CONNECT wird von Proxyservern verwendet, die in der Lage sind, SSL-Tunnel zur Verfügung zu stellen.

RFC 5789 definiert in Abgrenzung zu PUT für den Upload der kompletten Ressource, zusätzlich eine PATCH-Methode, um Ressourcen zu modifizieren.

Die HTTP-Erweiterung WebDAV fügt folgende Methoden zu HTTP hinzu:
PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK

Parameterübertragung

Häufig will ein Nutzer Informationen an eine Website senden. Dazu stellt HTTP prinzipiell zwei Möglichkeiten zur Verfügung:

HTTP-GET

Die Daten sind Teil der URL und bleiben deshalb beim Speichern oder der Weitergabe des Links erhalten.
Hier werden die Parameter-Wertepaare durch das Zeichen ? in der URL eingeleitet. Oft wird diese Vorgehensweise gewählt, um eine Liste von Parametern zu übertragen, die die Gegenstelle bei der Bearbeitung einer Anfrage berücksichtigen soll. Häufig besteht diese Liste aus Wertepaaren, welche durch das &-Zeichen voneinander getrennt sind. Die jeweiligen Wertepaare sind in der Form Parametername=Parameterwert aufgebaut.

Ein Beispiel:
Über die Schulungsseite für den Einfachen Einsatz von PHP wird eine Kontaktseite verfügbar. Dazu müssen wir dem Server aber mitteilen, dass wir auf die Kontaktseite wechseln wollen. Der Browser sendet die folgende Anfrage an den Server:

GET /simple/?page=kontakt HTTP/1.1
Host: php.nobs-nobody.de
...

Dem Server wird ein Schlüssel-Werte-Paar übergeben (wie gesagt: mit einem &-Zeichen verknüpft kann man auch mehrere Schlüssel-Werte-Paare übertragen):

Parameter Wert
page kontakt

Dieses Wertepaar wird in der Form
Parameter=Wert
mit vorangestelltem ? an die geforderte Seite angehängt.
Dadurch „weiß“ der Server, dass der Nutzer die Kontaktseite betrachten will. Der Server verarbeitet die Anfrage und sendet die entsprechende Datei:

HTTP/1.0 200 OK
Date: Wen, 10 Jul 2013 15:12:48 GMT
Last-Modified: Tue, 9 Jul 2013 11:18:20 GMT
Content-Language: de
Content-Type: text/html; charset=utf-8
<html>
<head>
...
</head>
<body>
...

Der Datenteil ist natürlich länger, hier soll nur das Protokoll betrachtet werden.

HTTP-POST

Übertragung der Daten mit einer speziell dazu vorgesehenen Anfrageart im HTTP-Body, so dass sie in der URL nicht sichtbar sind.
Die zu übertragenden Daten müssen ggf. URL-kodiert werden, d. h. reservierte Zeichen müssen mit „%<Hex-Wert>“ und Leerzeichen mit „+“ dargestellt werden.
Da sich die Daten nicht in der URL befinden, können per POST große Datenmengen, z. B. Bilder, übertragen werden.

Im folgenden Beispiel wird wieder die Kontaktseite angefordert, doch diesmal verwendet der Browser das Formular aus der vorherigen Antwort des Servers und eine POST-Anfrage. Die Parameter stehen dabei nicht in der URL, sondern werden durch einen Klick auf den Button im Body-Teil zum Server versendet:

POST /simple/?page=kontakt HTTP/1.1
Host: php.nobs-nobody.de
Content-Type: application/x-www-form-urlencoded
Content-Length: 66

name=nobs&email=nobs-nobody@gmx.de&quest=Testanfrage&submit=submit

Auch das versteht der Server und antwortet wieder mit beispielsweise folgendem Text:

HTTP/1.0 200 OK
Date: Wen, 10 Jul 2013 15:12:48 GMT
Last-Modified: Tue, 9 Jul 2013 11:18:20 GMT
Content-Language: de
Content-Type: text/html; charset=utf-8
<html>
<head>
...
</head>
<body>
...

Quelle: Wikipedia