Der HTTP-Request: Daten vom Server holen

HTTP – Hypertext Transfer-Protokoll

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 neue 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 bringt 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

HTTP 1.1 Request

(Angabe einer voll qualifizierten URL und die Headerzeile HOST erforderlich)

GET http://wisotop.de/test.html HTTP/1.1
HOST: wisotop.de

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.

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de; rv:1.8.0.4)
            Gecko/20060508 Firefox/1.5.0.4
Accept: */*

Das Acceptfeld signalisiert dem Server, welche Formate der Client akzeptiert. Da moderne Server nahezu alle Formate verarbeiten können, wird meist der Mime-Typ */* verwendet.

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/1.1 200 OK
Server: Apache/2.0.49 
Content-Language: de
Content-Type: text/html
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/312.8

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 Antwort kann ebenfalls Headerzeilen enthalten, von denen jede aus einem Header und einem Wertepaar besteht.

HTTP Status Code: HTTP/1.1 200 OK
Server: Apache/2.0.49 (Linux/SuSE)
Date: Thu, 13 Jul 2006 07:19:43 GMT
Content-Type: text/html
Connection: close

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 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/1.1 und HTTP/2

HTTP1 wurde 1996 definiert, als Webseiten nur selten mehr als 20 KB erreichten, als CSS noch über den Wolken hing und Javascript nur für die Validierung von Formularen und simple Effekte eingesetzt wurde.

HTTP/1.1 wurde 1997 vorgestellt, 1999 und 2014 gab es Updates. Der wichtigste Unterschied dürfte die Unterstützung mehrerer Verbindungen pro Request sein. Mehrere Verbindungen – das bringt eine kürzere Latenzzeit (Verzögerung zwischen Request und Response).

HTTP/2 ist die jüngste Fassung. Der Server kann Daten übertragen, die vom Client noch gar nicht angefordert wurden, die aber für die vollständige Darstellung der Seite gebraucht werden. HTTP/2 kann zusätzliche Requests über eine einzige TCP-Verbindung bündeln und gleichzeitig übertragen – auf die Antwort zu warten: kürzere Wartezeiten.

Sowohl Server also auch Client müssen HTTP/2 unterstützen – alle modernen Browser schaffen das. Wenn der Server HTTP/2 unterstützt, holt sich der Browser die Seiten automatisch über HTTP/2. HTTPS erforderlich: Wenn der Browser keine verschlüsselte Verbindung aushandeln kann, fällt er auf HTTP/1.1-Protokoll zurück.

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.

Ob die Seiten über HTTP 1.1 oder HTTP 2 geliefert werden, kann man 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.

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.