HTTP

Geschichte

Die Geschichte von HTTP beginnt im Jahr 1989. Zu dieser Zeit arbeitete Sir Tim Berners-Lee als Physiker am CERN. Mit seinem Vorschlag "Information Management, A Proposal" legte Berners-Lee (zunächst noch unter dem Arbeitstitel "Mesh") die konzeptionellen Grundlagen für das, was wir heute als World Wide Web kennen.

Grafik: Originaldarstellung des "Mesh" (Berners-Lee 1989)
Quelle: https://www.w3.org/History/1989/Image1.gif

Zwischen März 1989 und August 1991 erarbeiteten Berners-Lee und ein Team von Forschern die Spezifikationen und Beispielimplementierungen für die vier grundlegenden Säulen des Web:

  1. Das Hypertext Transfer Protokoll (HTTP), ein einfaches Protokoll zur Übertragung von Daten in einem Rechnernetz.
  2. Die Hypertext Markup Language (HTML), ein textuelles Auszeichnungsformat für Hypertext-Dokumente, die über HTTP übertragen werden.
  3. Den ersten Webserver ("httpd"), der Zugriff auf in HTML ausgezeichnete Hypertext-Dokumente in einem Rechnernetz erlaubte.
  4. Den ersten Browser ("WorldWideWeb"), der diese HTML-Dokumente bei einem Webserver anfragen und nach Empfang darstellen konnte.

Am 6. August 1991 veröffentlichte Berners-Lee seine Forschungsergebnisse unter anderem im Rahmen eines Posts an die alt.hypertext Newsgroup. Die Standardisierung von HTTP erfolgte durch die Internet Engineering Task Force und das World Wide Web Consortium. Der erste Vorschlag von HTTP wurde im Nachhinein als HTTP/0.9 festgelegt. Es folgten die offiziellen Standards HTTP/1.0 (1996), HTTP/1.1 (1999; diese Protokollversion ist bis heute hauptsächlich in Verwendung) sowie HTTP/2 (2015; RFC 7540 und RFC 7541).

Die öffentliche Verfügbarmachung der HTTP-Spezifikation und der dazugehörigen Referenzimplementierungen hat maßgeblich dazu beigetragten, dass sich die in den Jahren 1989–1991 grundgelegten Konzepte weltweit durchsetzten. Folgende Grafik hält die weiteren technischen Entwicklungen seit 1991 fest:

Grafik: "Die Evolution des Web"
Quelle: http://www.evolutionoftheweb.com

Weiterführende Informationen:

Definition und Grundlagen

"HTTP ist ein zustandsloses Protokoll zur Übertragung von Daten auf der Anwendungsschicht über ein Rechnernetz. Es wird hauptsächlich eingesetzt, um Webseiten (Hypertext-Dokumente) aus dem World Wide Web (WWW) in einen Webbrowser zu laden. Es ist jedoch nicht prinzipiell darauf beschränkt und auch als allgemeines Dateiübertragungsprotokoll sehr verbreitet." (Quelle: Wikipedia)

Die Kommunikation über HTTP erfolgt client-server basiert. Als Transportschicht für die Kommunikation kommt häufig TCP/IP (Transmission Control Protocol/Internet Protocol) zum Einsatz. Innerhalb des OSI Referenzmodells für die Einordnung von Netzwerkprotokollen befindet sich HTTP auf Ebene 7 (der Anwendungsschicht).

Open Systems Interconnection Model

Grafik: Das OSI-Schichtenmodell und HTTP (Hock-Chuan 2017)
Quelle: https://www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html

Zu den Grundkonzepten von HTTP gehören die Anfrage (Request) des Client, die Antwort (Response) des Servers, Uniform Resource Identifiers (URIs) zur Adressierung der Ressourcen sowie eine einfache Nachrichtenstruktur.

Client und Server tauschen innerhalb eines HTTP-Request-Response Zyklus Nachrichten aus. Handelt es sich beim Client um einen Webbrowser, kommen häufig weitere Technologien (bspw. CSS und JavaScript) zum Einsatz, um die Nachrichten (bspw. die HTML-Dokumente) in adäquater Form darzustellen oder zusätzliche Funktionalitäten anzubieten.

https://mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png

Grafik: Die building blocks des World Wide Web (Mozilla Developer Network)
Quelle: https://mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png

HTTP wird nicht nur zur Übertragung von Webseiten verwendet. Es kann in Form sogenannter Webservices auch direkt in Anwendungen zum Einsatz kommen. Hierbei werden die HTTP-Befehle dazu benutzt, um in den Anwendungen bestimmte Aktionen (z.B. das Anlegen oder Löschen eines Datensatzes) auszulösen.

HTTP-Nachrichten

HTTP-Nachrichten sind textbasiert und untergliedern sich in die Request-Nachricht (Anfrage, Client) und die Response-Nachricht (Antwort, Server).

HTTP Request-Response Zyklus

Grafik: HTTP Request-Response Zyklus (Hock-Chuan 2017)
Quelle: https://www.ntu.edu.sg/home/ehchua/programming/webprogramming/images/HTTP_Steps.png

Ein Request-Response Zyklus ist immer abgeschlossen und somit zustandslos. Es gibt zwischen mehreren Request-Response Zyklen keinen kontinuierlichen Datenstrom. Eine HTTP-Nachricht enthält immer einen Nachrichtenkopf (Message Header) und einen Nachrichtenrumpf (Message Body) mit dem Nachrichteninhalt.

Format einer HTTP-Nachricht

Grafik: Bestandteile einer HTTP-Nachricht (Hock-Chuan 2017)
Quelle: https://www.ntu.edu.sg/home/ehchua/programming/webprogramming/images/HTTP_MessageFormat.png

Da es sich bei HTTP um ein textbasiertes Protokoll handelt, können die Nachrichten auf allen an der HTTP-Kommunikation beteiligten Rechnern gelesen werden. Eine Verschlüsselung der Nachrichten kann im Rahmen einer Übertragung mittels HTTPS erfolgen. Hierbei wird eine zusätzliche Transportverschlüsselung zwischen HTTP und TCP/IP geschaltet. Die Verschlüsselung der Daten geschieht mittels SSL/TLS.

Der Nachrichtenfluss über HTTP erfolgt somit in folgenden Schritten:

  1. Der Client öffnet eine Verbindung (über TCP/IP).
  2. Der Client sendet eine HTTP-Nachricht (Request) an einen Server.
  3. Der Server empfängt die Nachricht und verarbeitet sie.
  4. Der Server sendet eine HTTP-Nachricht an den Client (Response).
  5. Der Client empfängt die Nachricht und verarbeitet sie.
  6. Die Verbindung wird geschlossen.

Wird HTTP/1.1 verwendet, kann die Verbindung zwischen Client und Server für weitere Anfragen wiederverwendet bzw. offen gehalten werden. Dies ändert nichts an der Zustandslosigkeit eines Request-Response Zyklus, ist jedoch effizienter. Mit HTTP/2 können mehrere Anfragen in einem Request-Response Zyklus zusammengefasst werden. Zudem sind die Nachrichten binär kodiert und nicht mehr direkt lesbar. HTTP/2 ist abwärtskompatibel zu HTTP/1.

Weiterführende Informationen

URIs

Das Ziel einer HTTP-Anfrage ist immer eine Ressource. Eine Ressource ist hierbei ein abstraktes Konzept und kann für unterschiedliche Dinge stehen - bspw. ein HTML-Dokument, ein Bild, ein Film oder - im Sinne des Semantic Web - ein "Ding" in der Welt, zu dem Informationen existieren (bspw. eine Person, ein Ort, aber auch ein Konzept etc.).

"A resource is not necessarily accessible via the Internet; e.g., human beings, corporations, and bound books in a library can also be resources. Likewise, abstract concepts can be resources, such as the operators and operands of a mathematical equation, the types of a relationship (e.g., 'parent' or 'employee'), or numeric values (e.g., zero, one, and infinity)." (Quelle RFC 3986, Abschnitt 1.1)

Jede Ressource hat mindestens einen global eindeutigen Identifikator, der sie von anderen Ressourcen unterscheidet. Dieser Identifikator ist der Uniform Resource Identifier (URI). Der Identifikator einer Ressource und der Ort, an dem sich die konkrete Ressource befindet, müssen dabei nicht notwendigerweise übereinstimmen. Hierin liegt der Unterschied zwischen einem URI und dem Uniform Resource Locator (URL), der einen "Zeiger" auf den konkreten Ort einer Ressource darstellt.

HTTP verwendet zur Identifikation von Ressourcen URIs. Häufig fallen dabei die Identität und der Ort einer Ressource, also URI und URL, zusammen. Der Vorteil ist, dass HTTP-URIs über das Domain Name System (DNS) direkt aufgelöst werden können. Es ist also möglich, mittels einer HTTP-URI direkt zur Ressource bzw. einer Repräsentation der Ressource (bspw. in Form eines HTML-, XML- oder JSON-Dokumentes) zu gelangen.

HTTP-URIs haben eine standardisierte Syntax und bestehen aus den folgenden Komponenten:

Scheme

Das Schema beschreibt den Typ einer URI. Als Schemas können sowohl standardisierte Protokolle (wie bspw. "http" oder "ftp") als auch anwendungsspezifische Protokolle (wie bspw. "git" oder "ssh") oder auch Namensräume (bspw. "urn" oder "doi") verwendet werden. Die Schema-Angabe wird durch einen Doppelpunkt (:) beendet. Das Schema ist ein obligatorischer Bestandteil eines URI.

Authority

Die Authority beschreibt die Instanz, welche die Namen in dem vom Schema angegeben Interpretationsraum verwaltet. Bei HTTP-URIs erfolgt dies im Rahmen des Domain Name Systems (DNS), das von Registraren verwaltet wird. Eine vollständige HTTP-Authority-Angabe besteht aus Nutzername:Passwort:Host:Port. Hierbei sind die Elemente Nutzername, Passwort und Port optional. Die Host-Angabe kann entweder eine IP-Adresse, eine IPv6-Adresse oder ein registrierter Domainname sein. Die Authority wird durch zwei Schrägstriche (//) eingeleitet und durch einen Schrägstrich (/), ein Fragezeichen (?) oder ein Doppelkreuz (#) beendet. Die Authority ist ein optionaler Bestandteil eines URI.

Path

Beim Pfad handelt es sich im Zusammenspiel mit dem Query um den Bestandteil eines URI, der die jeweilige Ressource eindeutig identifiziert. Er kann unterschiedlich organisiert sein. Eine Möglichkeit ist eine an ein Dateisystem angelehnte hierarchische Form ("/pfad/zur/ressource"). Genauso gültig sind aber Pfadkomponenten, die durch Doppelpunkte abgetrennt werden ("teil:eines:urn"). Der Pfad wird von einem Fragezeichen (?), Doppelkreuz (#) oder dem Ende des URI begrenzt und ist ein obligatorischer Bestandteil eines URI.

Query

Der Abfrageteil eines URI wird durch ein (?) eingeleitet und enthält Daten zur Identifizierung einer Ressource, die nicht allein durch den Pfad ausgedrückt werden (bspw. wenn die Ressource aus einer Datenbank abgerufen wird). Ein Query setzt sich aus einem oder mehreren Schlüssel=Wert Paaren zusammen, die durch ein Ampersand (&) miteinander verbunden werden. Der Abfrageteil eines URI ist optional und wird entweder durch das Doppelkreuz (#) oder das Ende des URI begrenzt. Der Abfrage-Teil eines HTTP-URI kann dazu verwendet werden, um Daten zu dieser Ressource über die Request-Methoden GET und POST an den Server zu übertragen.

Fragment

Der Fragmentenbezeichner referenziert eine spezifische Stelle innerhalb einer Ressource. Er bezieht sich immer auf die jeweilige URI und ist immer das letzte (optionale) Element eines URI.

URI vs. URN vs. URL

Häufig fällt die Unterscheidung zwischen URIs, URNs und URLs nicht leicht. Bei Uniform Resource Identifiern (URIs) handelt es sich um global eindeutige Identifikatoren für Ressourcen. Bei URNs und URLs handelt es sich um spezifische (Unter-)typen von URIs. Ein Uniform Resource Name (URN) ist ein URI mit dem Schema "urn", der einer Ressource einen dauerhaften, ortsunabhängigen Namen gibt. Der Uniform Resource Locator (URL) wiederum beschreibt den Ort einer Ressource eindeutig.

Eine URN sagt aus, um wen oder was es sich handelt, während eine URL sagt, wo (an welchem Ort) sich das Objekt (die Ressource) befindet. Quelle: Wikipedia

Da URNs ortsunabhängige Namen für Ressourcen sind, können sie nicht direkt aufgerufen werden. Sie müssen erst in URLs oder URIs übersetzt werden.

Weiterführende Informationen

Requests

Ein HTTP-Request besteht aus folgenden verbindlichen Elementen: Der HTTP-Methode, dem Pfad zu der angefragten Ressource, der Protokoll-Version und (in HTTP/1.1) dem Hostname. Optional können in einem HTTP-Request zusätzliche Header sowie ein Body (Nachrichtenrumpf) an den Server gesendet werden.

Grafik: Bestandteile eines HTTP-Requests
Quelle: MDN, https://mdn.mozillademos.org/files/13687/HTTP_Request.png

Request Header

Der Client kann seinem HTTP-Request bestimmte Header mitgeben. Ein Header besteht dabei immer aus Schlüssel: Wert Paaren. Der Schlüssel beginnt dabei immer mit einem Großbuchstaben. Nachfolgend eine Übersicht über die wichtigsten Request-Header:

Schlüsselwort Werte (Beispiele) Kurzbeschreibung
Host: de.wikipedia.org
Accept: text/html MIME Types
Accept-Language: en-GB HTTP 1.1 Spezifikation
Accept-Charset: UTF8
Accept-Encoding: x-gzip
Connection: Close/Keep-Alive
Referer: https://www.wikipedia.org/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X x.y; rv:42.0) Gecko/20100101 Firefox/42.0
Content-Length: 3495
Content-Type: text/html
Cache-Control: max-age=3600
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
Cookie: PHPSESSID=298zf09hf012fh2
If-Modified-Since: Sun, 31 Dez 2017 07:28:00 GMT

Weiterführende Informationen:

Info
Für die folgenden Aufgabe sollten Sie den Atom Editor mit dem Rester package auf ihrem Rechner installiert haben.

Request Methoden

Die HTTP-Spezifikation definiert die folgenden Request-Methoden, die von Clients für Anfragen an den Zielserver verwendet werden können. Die Request-Methode wird dabei in Großbuchstaben als erstes Element in der HTTP-Nachricht des Clients definiert. Die Request-Methode wird auch HTTP-Verb genannt. Nicht alle Webserver implementieren sämtliche Methoden der HTTP-Spezifikation. Andererseits können Server die Request-Methoden auch um eigene anwendungsspezifische Verben bzw. Funktionalitäten erweitern.

Requests abschicken und Antworten analysieren

Verwenden Sie in den folgenden Abschnitten Atom und das Rester Plugin um die Beispiel-Anfragen zu jeder beschriebenen HTTP-Methode abzuschicken. Analysieren Sie die vom Server zurückgegebenen Antworten

GET

Mittels GET fordert ein Client eine Ressource unter Angabe eines URI vom Server an. Eine GET-Anfrage darf dabei nur Daten abrufen und sonst keine Seiteneffekte erzeugen (wie bspw. eine Datenänderung auf dem Server). Je nach Server kann es eine maximale Länge für den angefragten URI geben (laut der Spezifikation 255 Bytes, gegenwärtig eher zwischen 2kb - 8kb). Die verschiedenen Clients und Server implementieren die maximale Länge eines URI unterschiedlich (Diskussion hierzu auf Stack Overflow).

GET /wiki/Digital_Humanities HTTP/1.1
Host: de.wikipedia.org
Accept: text/html
Accept-Language: de-DE
HEAD

Analog zur GET-Methode kann mittels HEAD eine Ressource auf einem Server angefragt werden. Bei Erfolg liefert der Server dabei aber keinen Nachrichtenrumpf sondern nur die Kopfdaten zurück. Da die Kopfdaten den Zeitstempel mit der letzten Aktualisierung der angefragten Ressource enthalten, kann der Client auf diese Weise prüfen, ob eine lokale Kopie der angefragten Ressource noch gültig ist oder mittels eines GET-Requests aktualisiert werden sollte.

HEAD /wiki/Digital_Humanities HTTP/1.1
Host: de.wikipedia.org
POST

Mittels POST kann eine (gemäß der Spezifikation unbegrenzte, in der Praxis je nach Serverimplementierung aber limitierte) Datenmenge an den Server übertragen werden. Der Nachrichtenrumpf enthält hierbei die zu übertragenden Daten. Im Falle eines HTML-Formulars, das über POST versendet wird, sind dies Name=Wert Paare. Wie der Server die eingehenden Daten verarbeitet ist nicht Bestandteil der Spezifikation (bspw. ob neue Ressourcen angelegt oder bestehende aktualisiert werden).

Nachrichtenrumpf als JSON:

POST /posts HTTP/1.1
Host: jsonplaceholder.typicode.com
Content-type: application/json

{
    "userId": 99,
    "id": 101,
    "title": "Foo",
    "body": "Bar"
}

Nachrichtenrumpf als HTML-Formular:

POST /posts HTTP/1.1
Host: jsonplaceholder.typicode.com
Content-type: application/x-www-form-urlencoded

userId=99
id=101
title=Foo
body=Bar
PUT

Mit der PUT-Methode kann eine Ressource auf dem Server unter der angegebenen URI angelegt oder ersetzt werden. Existiert eine Ressource nicht, wird sie erstellt. Existiert sie bereits, wird sie ersetzt.

PUT /albums/1 HTTP/1.1
Host: jsonplaceholder.typicode.com
DELETE

Mit der DELETE-Methode kann eine Ressource auf dem Server unter der angegebenen URI gelöscht werden.

DELETE /albums/1 HTTP/1.1
Host: jsonplaceholder.typicode.com
TRACE

Die TRACE-Methode kann zur Fehleranalyse verwendet werden. Sie liefert die Anfrage so zurück, wie der Server sie empfangen hat. Da hierbei Systeminformationen nach außen gelangen wird diese Methode im Produktivbetrieb aus Sicherheitsgründen meistens deaktiviert.

OPTIONS

Mit der OPTIONS-Methode kann der Client den Server nach den verfügbaren Request-Methoden fragen. Dies ist im Rahmen von Web-APIs hilfreich um programmtechnisch zu erkennen, welche Aktionen am Einstiegspunkt einer Web-API verfügbar sind. Die verfügbaren Methoden werden im Allow Header zurückgeliefert.

OPTIONS / HTTP/1.1
Host: www.w3.org
CONNECT

Die CONNECT-Methode kann verwendet werden um einem Proxy-Server mitzuteilen, sich direkt mit einem angefragten Zielsystem zu verbinden. Diese Methode spielt bei SSL-Verbindungen über Proxy-Server eine Rolle.

Sichere Methoden und Idempotente Methoden

HTTP als Protokoll ist zustandslos. Dennoch können über die genannten Request-Methoden Zustandsänderungen auf einem Zielsystem ausgelöst werden. Damit dies sowohl für die Client- als auch die Serverseite transparent erfolgt, sieht die HTTP-Spezifikation sichere und idempotente Methoden vor.

Als sichere Methoden gelten hierbei GET und HEAD. Sie sollen unter keinen Umständen Veränderungen auf dem angefragten System auslösen und dienen lediglich dem Abruf von Ressourcen. Dadurch kann den Methoden POST, PUT und DELETE eine klar getrennte, zustandsverändernde Funktion eingeräumt werden.

Idempotente Methoden müssen bei mehrfacher gleicher Ausführung (N > 0) immer das selbe Ergebnis zurückliefern. Hierzu gehören die Methoden GET, HEAD, PUT, DELETE, OPTIONS und TRACE. Beispiele hierfür sind das nur einmalige Erstellen oder Löschen einer Ressource beim wiederholten Aufruf des gleichen URI (eine Ressource unter demselben URI kann nicht mehrfach gelöscht werden).

Responses

Eine HTTP-Response besteht aus folgenden verbindlichen Elementen: Der verwendeten Protokoll-Version, dem Status-Code, und einer Status-Message. Optional kann eine HTTP-Response zusätzliche Header sowie - je nach angefragter Methode - einen Body (Nachrichtenrumpf) enthalten.

Grafik: Bestandteile einer HTTP-Response
Quelle: MDN, https://mdn.mozillademos.org/files/13691/HTTP_Response.png

Response Header

Der angefragte Server schickt in seiner HTTP-Antwort ebenfalls spezifische Header an den Client. Nachfolgend eine kurze Übersicht über gängige Antwort-Header:

Schlüsselwort Werte (Beispiele) Kurzbeschreibung
Date: Sun, 31 Dec 2017 12:20:58 GMT Zeitpunkt des Absendens
Connection: Close/Keep-Alive Status der HTTP-Verbindung
Content-Encoding: gzip Ressourcen können vor dem Absenden vom Server aus Effizienzgründen komprimiert werden. Dieser Header gibt die Art der Komprimierung an, nicht den Zeichensatz, in dem der Inhalt kodiert ist
Content-Length: 3495 Länge des Nachrichtenrumpfes in Bytes
Content-Type: text/html; charset=utf-8 MIME-Type des Nachrichteninhaltes mit Zeichensatz
Location: some/other/page.html Im Falle von Weiterleitungen Ort der Ressource, auf die weitergeleitet wird
Server: Apache Serverkennung

Weiterführende Informationen:

Response Status Codes

Die HTTP-Spezifikation sieht vor, dass ein Server bei jeder HTTP-Antwort auch einen Statuscode mitliefert. Der Statuscode gibt Aufschluss darüber, ob eine Anfrage erfolgreich war, ob bestimmte Fehler aufgetreten sind (bspw. eine ungültige Anfrage des Client oder ein Softwareproblem auf dem Server) oder (im Falle von Umleitungen) wo bestimmte Ressourcen zu finden sind oder ob eine Authentifizierung für den Abruf bestimmter Ressourcen notwendig ist. Eine gute Kenntnis möglicher HTTP-Statuscodes ist insbesondere bei der webbasierten API-Programmierung wichtig:

HTTP-Statuscodes werden in fünf Bereiche eingeteilt.

1xx - Die Bearbeitung der Anfrage dauert noch an.

HTTP-Statuscodes in dieser Range werden verwendet, um dem Client eine noch nicht abgeschlossen Bearbeitung zu signalisieren und somit einen Timeout zu verhindern.

2xx - Die Anfrage war erfolgreich

In dieser Range finden sich Statuscodes, die eine erfolgreiche Anfrage signalisieren (insbesondere 200 - Ok und 201 - Created).

3xx - Weitere Schritte seitens des Clients sind erforderlich

Statuscodes aus dieser Range werden häufig bei Umstrukturierungen oder Umleitungen von Webseiten oder Web-APIs gesendet. Häufig anzutreffen sind die Codes 301 - Moved Permanently, 302 - Found (Moved Temporarily) und 303 - See Other. Der Location-Header in der HTTP-Antwort zeigt dem Client an, unter welcher URI die angefragte Ressource nun zu finden ist.

4xx - Ein Fehler ist aufgetreten. Die Ursache liegt (eher) im Verantwortungsbereich des Clients

HTTP-Statuscodes in dieser Range weisen Fehler aus, die häufig in Verbindung mit der Anfrage des Clients stehen. Besonders häufig ist der Statuscode 404 - Not Found, der verwendet wird, wenn eine angefragte Ressource nicht unter der entsprechenden URI gefunden werden konnte. Weitere häufig anzutreffende Statuscodes in dieser Range sind 403 - Forbidden (Zugriff für den Client verweigert) und 401 - Unauthorized (fehlende Authentifizierung für den Zugriff) und 400 - Bad Request (ungültige Anfrage).

5xx - Ein Fehler ist aufgetreten. Die Ursache liegt (eher) im Verantwortungsbereich des Servers

Die in dieser Range befindlichen HTTP-Statuscodes weisen Fehler aus, die (wahrscheinlich) auf dem Server bei der Verarbeitung der Anfrage geschehen sind. Gibt es beispielsweise auf dem Webserver, der die Anfrage verarbeitet, einen Fehler der dazu führt, dass die Anfrage nicht verarbeitet werden kann, wird der Fehlercode 500 - Internal Server Error zurückgegeben. Im Bereich von Webanwendungen kann dies häufig auch der Fall sein, wenn die Ausführung der jeweiligen Webanwendung, die für die Erzeugung des Inhalts der HTTP-Antwort verantwortlich ist, durch einen Programmfehler beendet wird. Bei hoher Auslastung eines angefragten Servers oder einer Fehlkonfiguration wird meistens der Statuscode 503 - Service Unavailable zurückgegeben.

Connection Management

In Zeiten von HTTP/1.0 wurde mit jeder HTTP-Anfrage eine neue TCP/IP Verbindung geöffnet. Für jede Ressource, die bei einer Anfrage bezogen werden muss (bei einer Webseite bspw. auch Bilder, CSS und JavaScript-Dateien) musste eine eigene Verbindung geöffnet werden. Das Laden von HTTP-Ressourcen im Browser erfolgt sequentiell. Neue Request-Response Zyklen werden erst begonnen, nachdem vorherige Zyklen abgeschlossen sind. HTTP/1.1 verbesserte diese Situation durch die Einführung von persistenten Verbindungen (d.h. einmal stehende Verbindungen zwischen Client und Server werden offen gehalten für weitere Anfragen).

Ein in generelles Ziel zur Steigerung der Performanz von Webanwendungen ist es aber immer noch, die Anzahl der notwendigen TCP/IP Verbindungen zum Laden einer Webseite möglichst gering zu halten. Diese Situation genügt heutigen Maßstäben und Anforderungen an moderne Webanwendungen nicht mehr.

Der 2014 verabschiedete HTTP/2 sieht daher mit dem Multiplexing ein neues und deutlich effizienteres Verbindungsmodell vor.

Weiterführende Informationen

Content Negotiation

Content Negotiation (etwa: "Inhaltsvereinbarung") gehört zu den wichtigsten Konzepten in HTTP und beschreibt eine "Absprachemöglichkeit" zwischen Client und Server zur gezielten Auslieferung bestimmter Repräsentationsformen einer angefragten Ressource. Eine über eine URI adressierte Ressource verfügt als abstrakte Entität über keine eigene "Dinglichkeit". Hinter einer URI können aber eine oder mehrere Repräsentationen für die Ressource stehen (bspw. in Form einer HTML-, XML- oder PDF-Datei).

In HTTP/1.1 kommt am häufigsten die serverseitige Content Negotiation zum Einsatz. Sie basiert auf den folgenden vier Request-Headern: Accept, Accept-Charset, Accept-Encoding und Accept-Language.

Grafik: Serverseitige Content Negotiation
Quelle: MDN, https://mdn.mozillademos.org/files/13791/HTTPNegoServer.png

Der Server antwortet auf diese vier Request-Header mit den drei Response-Headern Content-Type (enthält MIME-Type und Zeichensatz der Ressource), Content-Encoding (enthält Komprimierungsform) und Content-Language (enthält Sprachinformation). Sofern die ausgelieferte Repräsentation einer Ressource eine andere URL besitzt, kann der Server diese zudem über den Content-Location Header mitteilen.

Anwendungsfälle für Content Negotiation bestehen beispielsweise in der Auslieferung sprachspezifischer Inhalte (Auslieferung einer Website in Französisch, wenn der Client den Accept-Language Header mit dem Wert "fr-FR" sendet) oder geeigneter Bildformate. Content Negotiation spielt auch im Semantic Web bei der Bereitstellung von RDF-Vokabularien und Ontologien sowie bei der Dereferenzierung von URIs eine wichtige Rolle.

Grafik: Dereferenzierung einer URI mittels Content Negotiation
Quelle: W3C, https://www.w3.org/TR/cooluris/img20081203/hash_conneg.png

Weiterführende Informationen

Authentication

Sollen bestimmte Webinhalte nur für einen eingeschränkten Nutzer_innenkreis zugänglich sein, sind Authentifizierungsmechanismen notwendig. HTTP sieht hierfür mehrere Möglichkeiten vor. Generell erfolgt der HTTP-Authentifizierungsmechanismus gemäß RFC 7235 folgendermaßen:

  1. Ein Client fragt einen Server nach einer Ressource an
  2. Der Server antwortet mit Statuscode 401 - Unauthorized und sendet einen WWW-Authenticate Header
  3. Der Client antwortet mit einer erneuten Anfrage und einem Authorization Header, der die Zugangsdaten enthält
  4. Der Server prüft die Zugangsdaten und Antwortet entweder mit Statuscode 200 - Ok oder 403 - Forbidden

Innerhalb des WWW-Authenticate Headers legt der Server fest, welche Authentifizierungsmethode verwendet wird. Die grundsätzlichste Methode ist hierbei die HTTP Basic Authentication. Bei dieser Methode werden Benutzeridentifikation und Passwort in base64 Kodierung im Reintext übertragen. Daher sollte diese Authentifizierungsmethode ausschließlich in Verbindung mit verschlüsselten HTTPS-Verbindungen verwendet werden.

HTTP Authentifizierung findet direkt zwischen Client und Server statt und ist nicht zu verwechseln mit (weiteren) Authentifizierungsmechanismen, die auf der Ebene von Webanwendungen (bspw. ein datenbankgestütztes Login) stattfinden.

Weiterführende Informationen

Session Management

Da es sich bei HTTP um ein zustandsloses Protokoll handelt, bleiben Sitzungsinformationen zwischen ein und demselben Client und Server nicht über einen Request-Response Zyklus hinaus erhalten. Funktionalitäten, die eine andauernde Sitzung benötigen (bspw. eine Login-Funktion, eine Warenkorb-Funktion etc.) müssen daher anwendungsseitig implementiert werden.

Protokolltechnisch geschieht dies durch die Generierung und das kontinuierliche Mitführen einer Session-ID. Hierbei muss die Anwendung einen eindeutigen Identifikator generieren, der vom Server an den Client übertragen wird und den dieser dann in allen folgenden Anfragen an den Server sendet. Dadurch kann der Server bzw. eine auf dem Server laufende Webanwendung den zugreifenden Client eindeutig identifizieren.

Das Management von Session-IDs kann in unterschiedlicher Weise erfolgen. Die einfachste Möglichkeit besteht im kontinuierlichen Mitführen der ID innerhalb von GET oder POST Requests. Bei GET-Requests erfolgt dies innerhalb einer Parameter:Wert Zuweisung im Query-Teil eines URI, bei POST-Anfragen beispielsweise in einem entsprechenden HTTP-Header. Beide Möglichkeiten bergen die Gefahr des Session Hijacking, also der unbefugten Übernahme einer Sitzung durch eine dritte Partei die in den Besitz einer gültigen Session-ID gelangt ist (zum Beispiel durch das Mitlesen der Informationen auf einem dritten System zwischen Client und Server, über das die jeweilige HTTP-Kommunikation läuft).

Die am häufigsten verwendete Methode zur Speicherung von Sitzungsdaten ist daher das HTTP-Cookie. Bei einem HTTP-Cookie handelt es sich um eine kleine Textdatei (maximale Größe 4KB), die vom Server mittels des Set-Cookie Headers an den Client versendet und dort (in Reintext) gespeichert wird. Ein Cookie kann neben der Session-ID auch noch weitere Sitzungsdaten enthalten, ist durch seine geringe Größe jedoch relativ eingeschränkt. Ein Server kann einem Client mehr als ein Cookie senden. Die Anzahl der Cookies pro Server ist jedoch auf 20 limitiert, insgesamt kann ein Client nicht mehr als 300 Cookies verwalten.

Weiterführende Informationen

WS 2019/20 – Webbasierte Forschungsapplikationen für die Geisteswissenschaften CC BY-NC-SA 4.0