Der HTTP-Request: Daten vom Server holen

HTTP – Hypertext Transfer-Protokoll

Für diesen Ablauf ist das HTTP-Protokoll zuständig. Protokolle regeln den Nachrichtenaustausch und die Formatierung von Daten zwischen Client (z.B. Browser) und Server. Die prominentesten Protokolle des Internets sind HTTP (Hypertext Transfer Protocol) und FTP (File Transfer Protocol). POP3 ist ein Protokoll für den Emailabruf, SSH (Secure Shell) ein verschlüsseltes Terminal für den Remote Zugang zum Server.

http-request-ablauf — Ablauf beim HTTP-Request

Wenn der Benutzer eine Adresse in das Adressfeld seines Browsers eingibt oder ein Formular an die Adresse im action-Attribut absendet, wird die Adresse als HTTP-Request an den Server geschickt. Der Browser ist der HTTP-Client und der Server ist der HTTP-Server.

HTTP ist ein zustandloses Protokoll. Nach einer Datenübertragung muss die Verbindung zwischen dem Client und dem Server nicht aufrecht erhalten werden.

Bei der Übertragung weiterer Daten muss der Client eine neue Verbindung aufbauen, die nichts über den vorangegangenen Ablauf weiß. Für eine Webseite mit vier Bildern und einem Stylesheet waren beim HTTP 1.0-Protokol noch sechs Anfragen erforderlich, das HTTP 1.1-Protokoll hingegen konnte schon mehrere Anfragen und Antworten innerhalb einer Verbindung austauschen und abgebrochene Verbindungen fortsetzen.

HTTP 2

Seit 2015 ist HTTP/2 der Standard – mit besserer Performance als HTTP/1.1, besserer Komprimierung des HTTP-Headers und vor allem Dank des Multiplexing mehrerer simultaner Requests auf derselben Verbindung.

Den ganz großen Durchbruch bei der Geschwindigkeit brachte HTTP/2 nicht, denn HTTP/2 ist kompatibel zu HTTP/1.1 geblieben und erfordert außerdem eine verschlüsselte Verbindung (HTTPS), die den Transfer einen Tick verlängert. Aber dank der Kompatibilität bleiben uns die lieben alten Funktionen vom Cookie bis zum GET und POST erhalten.

HTTP-Request und HTTP-Response

Nach dem Aufbau einer Verbindung zum Server überträgt der HTTP-Client einen Request in einem festgelegten Format:

eine Anfangszeile
eine Reihe von Headerzeilen
eine Leerzeile
eine Nachricht (optional)

Die dreiteilige Anfangszeile besteht aus dem Namen der Methode, dem Pfad zur angeforderten Ressource und der verwendeten HTTP-Version. Eine typische Anfrage kann folgendermaßen aussehen:

Headerzeilen senden zusätzliche Informationen über den Request oder die Daten des Nachrichtenbodys, z.B. die gewünschte Sprache. Jede Headerzeile vermerkt ein Name-/Wertpaar, wobei Name und Wert durch einen Doppelpunkt getrennt werden.

HTTP-Response

Als Antwort auf einen derartigen Request sendet der Server eine HTTP-Response, wobei die erste Zeile auch als Statuszeile bezeichnet wird. In dieser Zeile gibt der Server die HTTP-Version als Echo zurück sowie einen Response-Statuscode im Form von drei Ziffern und eine kurze Textnachricht, die als Reason Phase bezeichnet wird.

HTTP/2 200 
server: nginx
date: Mon, 05 Aug 2024 16:11:58 GMT
content-type: text/html; charset=UTF-8
content-length: 35737
vary: Accept-Encoding

Das können wir mit einem fetch- oder XMLHttp"#F8F8FF"Request ansehen:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'https://www.mediaevent.de/tutorial/http-request.json', true);

xhr.onreadystatechange = function () {
  if (xhr.readyState === 4) { // 4 bedeutet DONE
    console.log('Status:', xhr.status); // Statuscode der Antwort
    console.log('Headers:', xhr.getAllResponseHeaders()); // Alle Header der Antwort

    // Weder XMLHttpRequest noch fetch können die HTTP-Version zurückgeben
  }
};

xhr.send();

Die HTTP-Version des Servers kann allerdings weder mit fetch noch mittels XMLHttpRequest abgerufen werden, aber z.B. mit einem curl-Request auf der Kommandozeile:

curl -I https://www.mediaevent.de/tutorial/

Ob die Seiten über HTTP 1.1 oder HTTP 2 geliefert werden, kann man auch in der Chrome-Console testen:

console.log(performance.getEntries()[0].nextHopProtocol)

Bei HTTP2 ist die Antwort kurz und bündig h2, ansonsten http/1.1.

Der Response-Statuscode und die Reason Phase sind Klartext-Mitteilungen derselben Nachricht, wobei die Reason Phase von Server zu Server ein wenig variieren kann.

1** - Information: Informationsmeldungen
2**—Success: Die Anfrage wurde erfolgreich durchgeführt
200 - OK: Die Anfrage war erfolgreich
204 - No Content: Das Dokument enthält keine Daten
3**—Redirected: für eine erfolgreiche Bearbeitung der Anfrage werden weitere Informationen benötigt
301 - Moved Permanently: Das angefragte Dokument ist dauerhaft zu einer anderen URI umgezogen
4**—Client error: Wahrscheinlich liegt die Ursache für das Scheitern einer Anfrage beim Client
401 - Not Authorized: Der Request muss vom Benutzer authentifiziert werden
403 - Forbidden: Der Server weist den Request zurück
404 - Not Found: Die angeforderte Ressource existiert nicht
5**—Server error
500 - Internal Server Error: wahrscheinlich liegt die Ursache des Scheitern einer Anfrage beim Server
503 - Service Unavailable

Die HTTP-Request-Methoden

Mit den Methoden des HTTP-Requests sind wir vertraut, sobald wir das erste Formular auf eine Webseite setzen. Dabei beschränkt sich die Begegnung meist auf die Methoden GET und POST.

GET: Inhalte vom Server anfordern.
POST: Sendet Daten zum Server: Inhalte vom Server anfordern und zusätzlich einen Datenblock aus Name-/Wertpaaren (z.B. aus einem Formular) übermitteln. Grundsätzlich können Daten auch mit GET übertragen werden, aber die zulässige Datenmenge bei POST ist größer.
HEAD: Weist den Server an, den HTTP-Header, nicht jedoch den Inhalt des Dokuments zu senden. So kann z.B. die Existenz einer gelinkte Seite geprüft werden.
PUT: Führt ein Update auf einer Ressource durch – Dateien auf den Webserver laden. Wird aus Sicherheitsgründen kaum implementiert.
DELETE: Löscht die Datei auf dem Server. Wird aus Sicherheitsgründen kaum implementiert.
TRACE: liefert die Anfrage so zurück, wie der Server sie empfangen hat. Wird z.B. für das Debuggen von Verbindungen benutzt, ist aber auf vielen Servern aus Sicherheitsgründen nicht implementiert.
CONNECT: wird von Proxy-Servern implementiert
PATCH: Änderungen an einer Ressource

HTTP/2 – Auswirkungen auf das Webdesign

Auch wenn HTTP/2 Webseiten keine Flügel verleiht und vom Benutzer mehr oder minder kaum wahrgenommen wird, hat der Einsatz von HTTP/2 Auswirkungen auf das Webdesign.

Wo früher Image Spites viele relativ kleine Bilder zu einem großen Bild zusammen gesetzt haben, damit das CSS sie wieder auseinander pflückte, kann man sich diesen aufwändigen Prozess mit HTTP/2 in vielen Fällen sparen. Dasselbe gilt für das Zusammenstellen großer Javascript-Dateien aus der Vielzahl der verwendeten Scripte und auch für CSS-Dateien. Mit HTTP/2 bringen diese Verfahren nicht mehr dieselben Vorteile wie in HTTP/1.1, dafür u.U. aber neue Nachteile:

Der Benutzer bekommt große Dateien serviert, von denen er vielleicht nur einen Teil tatsächlich braucht. Mit HTTP/2 ist es sinnvoller, Ressourcen effizient nur dort einzusetzen, wo sie gebraucht werden.
Eine Base64-Data-URL ist ebenfalls eher kontraproduktiv im Vergleich zum Einbinden der Datei.
HTTP2 kann Inline-Inhalte nicht cachen. Modulare externe CSS- und Javascript-Dateien hingegen können effizient gecacht werden, ohne einen zusätzlichen Request zum Server anzufordern.

Die sichtbaren Geschwindigkeitsvorteile sind – wie bereits erwähnt – kein berauschender Höhenflug, sondern bei der Betrachtung der Ladezeit einzelner Seiten eher naja, nett. Sichtbar werden die Vorteile von HTTP 2 bei hohen Besucherzahlen in der Gesamtbeurteilung.

Cookies und Query-Strings

Aber auch mit HTTP/2 hat das HTTP-Protokoll kein Gedächtnis. Um Informationen von einer HTML-Seite auf die nächste Seite zu schaffen (z.B. bei mehrseitigen Formularen) müssen Verfahren wie Cookies, Query-Strings oder PHP-Session eingesetzt werden.