Was ist eine HTTP-Anfrage

Aufbau einer HTTP-Anfrage

Eine HTTP-Anfrage besteht aus drei Hauptteilen:

1. Request-Zeile: Diese enthält die HTTP-Methode (Verb), das Request-Ziel (das kann eine URI oder URL sein) und die HTTP-Version. Die HTTP-Methode gibt an, welche Art von Aktion mit der Ressource durchgeführt werden soll.

2. Header: Diese liefern zusätzliche Informationen über die Anfrage, wie zum Beispiel den User-Agent, Cookies, Content-Length und Authorization-Token. Header können auch angeben, welche Datentypen der Client akzeptieren kann.

3. Message-Body: Dieser Teil ist optional und wird verwendet, um Daten vom Client zum Server zu senden oder Informationen vom Server zum Client zu übermitteln. Der Message-Body wird oft beim Erstellen oder Aktualisieren einer Ressource auf dem Server genutzt.

So funktionieren HTTP-Anfragen

HTTP-Anfragen sind die wichtigste Form der Kommunikation zwischen einem Client und einem Server im World Wide Web. Wenn Sie eine URL in Ihren Browser eingeben oder auf einen Link klicken, sendet der Browser eine HTTP-Anfrage an den Server, der die Website hostet. Der Server prüft dann die Anfrage und sendet eine HTTP-Antwort zurück, die die angeforderte Ressource enthält (zum Beispiel eine HTML-Seite, ein Bild oder eine JavaScript-Datei). Diese Übertragung von Ressourcen erfolgt über das HTTP-Protokoll, das die Struktur und das Format der Anfragen und Antworten definiert, die zwischen Browser und Server ausgetauscht werden.

GET

Die GET-Methode wird verwendet, um eine Ressource von einem Server abzurufen. Sie ist die am häufigsten verwendete HTTP-Methode und wird jedes Mal genutzt, wenn Sie auf einen Link klicken oder eine URL in die Adressleiste Ihres Browsers eingeben. GET-Anfragen sollten nur zum Abrufen von Daten verwendet werden und den Zustand des Servers nicht verändern.

POST

Die POST-Methode sendet Daten an den Server, um eine Ressource zu erstellen oder zu aktualisieren. Die an den Server gesendeten Daten werden im Request-Body der HTTP-Anfrage gespeichert. Dies wird häufig beim Absenden von Formularen auf Websites verwendet.

PUT

Die PUT-Methode ist ähnlich wie POST, da sie eine Ressource erstellen oder aktualisieren kann. Allerdings führt ein mehrfaches Aufrufen einer PUT-Anfrage immer zum gleichen Ergebnis, während mehrere identische POST-Anfragen dieselbe Ressource mehrfach erstellen. PUT-Anfragen sind idempotent, POST-Anfragen hingegen nicht.

DELETE

Die DELETE-Methode löscht eine bestimmte Ressource auf dem Server. Sie enthält alle Informationen, die nötig sind, um die zu entfernende Ressource zu finden.

HEAD

Die HEAD-Methode ist identisch mit einer GET-Anfrage, jedoch ohne Response-Body. Dies ist nützlich, um Meta-Informationen über eine Ressource zu erhalten, ohne den gesamten Inhalt zu übertragen. HEAD-Anfragen werden oft verwendet, um Hyperlinks auf ihre Gültigkeit zu testen oder zu prüfen, ob eine Ressource geändert wurde.

PATCH

Die PATCH-Methode wendet teilweise Änderungen auf eine Ressource an. Sie ist ähnlich wie die PUT-Methode, wird aber für kleinere Änderungen verwendet, wie zum Beispiel die Änderung eines einzelnen Feldes in einem Datensatz.

OPTIONS

Die OPTIONS-Methode beschreibt die Kommunikationsoptionen für die Zielressource. Dies ermöglicht einem Client, die Optionen und Anforderungen zu bestimmen, die mit einer Ressource verbunden sind, ohne sie abzurufen.

TRACE

Die TRACE-Methode führt einen Message-Loop-Back-Test entlang des Pfades zur Zielressource durch. Sie wird für Debugging-Zwecke verwendet.

Jede dieser Methoden dient einem bestimmten Zweck bei der Kommunikation mit Servern und der Bearbeitung von Ressourcen. Durch die Verwendung der richtigen Methode für jede Aufgabe können Entwickler sicherstellen, dass ihre Anwendungen korrekt mit Servern interagieren.

Request-Zeile

Die Request-Zeile ist die erste Zeile einer HTTP-Anfrage. Sie enthält drei wichtige Informationen:

1. Die HTTP-Methode (Verb) - Diese zeigt die Art der Aktion an, die mit der Ressource durchgeführt werden soll. Gängige HTTP-Methoden sind GET, POST, PUT, DELETE und weitere, wie bereits besprochen.

2. Die Request-URL - Dies ist die URL der Ressource, auf der die Aktion durchgeführt werden soll. Sie kann ein absoluter Pfad oder eine vollständige URL sein.

3. Die HTTP-Version - Diese gibt die Version des verwendeten HTTP-Protokolls an, typischerweise HTTP/1.1 oder HTTP/2.

Hier ist ein Beispiel für eine Request-Zeile:

GET /products HTTP/1.1

Request-Header

HTTP-Header ermöglichen es dem Client, zusätzliche Informationen mit der Anfrage zu übermitteln. Header sind Schlüssel-Wert-Paare, die durch einen Doppelpunkt getrennt sind. Einige häufige Header sind:

• Host - Der Domain-Name des Webservers.
• User-Agent - Informationen über den Client, der die Anfrage stellt, wie zum Beispiel Browser-Typ und Version.
• Content-Type - Der MIME-Typ des Request-Body.
• Content-Length - Die Länge des Request-Body in Bytes.
• Authorization - Enthält Anmeldedaten zur Authentifizierung eines User-Agents beim Server.
• Cookie - Enthält Cookies, die zuvor vom Server gesendet wurden.

Hier ist ein Beispiel für einige Request-Header:

Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36
Content-Type: application/json

Request-Body

Der Request-Body ist optional und enthält die Daten, die an den Server gesendet werden. Dies wird typischerweise bei POST-, PUT-, PATCH- und manchmal DELETE-Anfragen verwendet. Die Daten können in verschiedenen Formaten vorliegen, wie zum Beispiel:

• Formulardaten - Schlüssel-Wert-Paare, die von HTML-Formularen gesendet werden.
• JSON - JavaScript Object Notation, ein häufiges Format für strukturierte Daten.
• XML - eXtensible Markup Language, ein weiteres Format für strukturierte Daten.
• Binärdaten - Wie zum Beispiel Bilder oder andere Dateien.

Hier ist ein Beispiel für einen JSON-Payload in einem Request-Body:

{
  "name": "John Doe",
  "age": 30,
  "city": "New York"
}

Das Verständnis der Anatomie einer HTTP-Anfrage ist wichtig für Webentwickler. Es ermöglicht ihnen, Anfragen korrekt zu strukturieren und alle notwendigen Informationen einzubeziehen, damit der Server sie richtig verarbeiten kann. Die HTTP-Anfrage enthält wichtige Informationen wie die Request-Methode, URL, Header und den optionalen Body, die der Webserver benötigt, um die Anfrage zu verstehen und zu erfüllen. Jede HTTP-Anfrage öffnet eine TCP-Verbindung, um die Anfrage zu senden und die Antwort zu empfangen. HTTP ist ein Anwendungsschicht-Protokoll, das diese Befehlssprache definiert, der die Geräte auf beiden Seiten der Verbindung folgen müssen, um miteinander zu kommunizieren.

Sichere Erweiterung von HTTP

HTTPS (Hypertext Transfer Protocol Secure) ist eine Erweiterung des Standard-HTTP-Protokolls, die eine Sicherheitsebene hinzufügt. Es verwendet bidirektionale Verschlüsselung, um die Kommunikation zwischen einem Client und einem Server zu sichern. Das bedeutet, dass alle Daten, die zwischen Client und Server ausgetauscht werden, verschlüsselt sind, was es für Dritte viel schwieriger macht, die Daten abzufangen und zu lesen.

HTTPS verwendet SSL (Secure Sockets Layer) oder TLS (Transport Layer Security) digitale Zertifikate auf der Serverseite, um sichere Verbindungen herzustellen. Wenn ein Client (normalerweise ein Webbrowser) sich mit einem HTTPS-Server verbindet, präsentiert der Server sein SSL/TLS-Zertifikat, um seine Identität nachzuweisen. Der Client überprüft dann dieses Zertifikat, bevor er eine verschlüsselte Verbindung herstellt.

Rolle der Zertifizierungsstellen

SSL/TLS-Zertifikate werden von vertrauenswürdigen Dritten ausgestellt, die als Zertifizierungsstellen (Certificate Authorities, CAs) bekannt sind. Die Aufgabe einer CA besteht darin, die Identität der Einheit zu überprüfen, die das Zertifikat anfordert (normalerweise der Inhaber einer Website oder Webanwendung), und das Zertifikat mit dem eigenen privaten Schlüssel der CA zu signieren.

Wenn ein Client ein SSL/TLS-Zertifikat von einem Server erhält, kann er die Signatur mit dem öffentlichen Schlüssel der CA überprüfen. Wenn die Signatur gültig ist und das Zertifikat nicht abgelaufen ist, kann der Client sicher sein, dass er mit dem echten Server und nicht mit einem Betrüger kommuniziert.

Dieser Prozess der Zertifikatsüberprüfung wird als SSL/TLS-Handshake bezeichnet. Er läuft automatisch im Hintergrund ab, wenn Sie sich mit einer Website über HTTPS verbinden. Das Vorhandensein eines gültigen Zertifikats und ein erfolgreicher Handshake stellen die Authentizität, Integrität und Vertraulichkeit der zwischen Client und Server ausgetauschten Daten sicher.

CAs spielen eine wichtige Rolle im Vertrauensmodell von HTTPS. Sie sind dafür verantwortlich, die Einheiten, denen sie Zertifikate ausstellen, gründlich zu prüfen und die Sicherheit und Integrität ihrer eigenen Signaturschlüssel zu wahren. Webbrowser und Betriebssysteme führen eine Liste vertrauenswürdiger CAs, und sie stellen nur vertrauenswürdige Verbindungen zu Servern mit Zertifikaten her, die von diesen CAs ausgestellt wurden.

Client-Server-Kommunikation

Die HTTP-Kommunikation basiert auf einem Client-Server-Modell. Der Client, normalerweise ein Webbrowser, sendet eine HTTP-Anfrage an den Server. Die Anfrage enthält die URL der Ressource, die HTTP-Methode (wie GET, POST usw.), Request-Header und manchmal einen Request-Body.

Der Server verarbeitet dann die Anfrage und gibt eine HTTP-Antwort zurück. Die Antwort enthält einen Statuscode, der anzeigt, ob die Anfrage erfolgreich war (z. B. 200 OK) oder ob es einen Fehler gab (z. B. 404 Not Found). Die Antwort enthält auch Header, die zusätzliche Informationen über die Antwort liefern, und normalerweise einen Message-Body mit den angeforderten Daten.

Wenn Sie zum Beispiel eine URL in Ihren Browser eingeben, sendet der Browser eine GET-Anfrage an den Server. Der Server sendet dann eine Antwort zurück, die den HTML-Inhalt der Webseite enthält. Der Browser analysiert dann dieses HTML und sendet zusätzliche Anfragen für alle anderen Ressourcen, die zur Anzeige der Seite benötigt werden, wie zum Beispiel Bilder, CSS-Stylesheets und JavaScript-Dateien.

Zugriff auf Ressourcen, die auf verschiedenen Servern gehostet werden

Eine einzelne Webseite enthält oft Ressourcen von mehreren Servern. Beispielsweise könnte eine Seite ihren Hauptinhalt von einem Server laden, ihre Bilder von einem anderen und Skripte oder Stylesheets von noch einem anderen Server. Das liegt daran, dass das Internet aus miteinander verbundenen Servern besteht, die jeweils ihre eigenen Ressourcen hosten.

Wenn Sie eine Webseite besuchen, muss Ihr Browser separate HTTP-Anfragen an jeden dieser Server senden, um alle Ressourcen zu erhalten, die er zur Anzeige der Seite benötigt. Er beginnt damit, das HTML-Dokument anzufordern, das Verweise auf andere Ressourcen wie Bilder, CSS und JavaScript-Dateien enthält. Der Browser sendet dann zusätzliche HTTP-Anfragen an die Server, die diese Ressourcen hosten.

Sobald der Browser alle notwendigen Ressourcen erhalten hat, rendert er die Webseite, indem er das HTML analysiert, die CSS-Stile anwendet und jeden JavaScript-Code ausführt. Dieser JavaScript-Code kann weiter mit der Seite interagieren, das HTML und CSS ändern und sogar zusätzliche HTTP-Anfragen an Server senden (so funktioniert AJAX).

Auch wenn es so scheinen mag, als würden Sie mit einer einzelnen Einheit interagieren, wenn Sie eine Website nutzen, läuft unter der Oberfläche ein komplexes Netzwerk von Client-Server-Interaktionen über HTTP ab.

Senden von Anfragen und Rendern von Antworten

Webbrowser sind die häufigsten HTTP-Clients. Wenn Sie eine URL in die Adressleiste eines Browsers eingeben oder auf einen Link auf einer Webseite klicken, sendet der Browser eine HTTP-Anfrage an den Server, der die Website hostet. Diese Anfrage enthält normalerweise die URL der Seite, die HTTP-Methode (normalerweise GET für normales Web-Browsing) und Header, die Informationen über den Browser liefern.

Sobald der Server mit den angeforderten Ressourcen antwortet, besteht die Aufgabe des Browsers darin, den Inhalt für den Benutzer zu rendern. Bei einer typischen Webseite bedeutet das, das HTML zu analysieren, um das Document Object Model (DOM) aufzubauen, CSS-Stile anzuwenden, um die Seitenelemente anzuordnen und zu gestalten, und jeden JavaScript-Code auszuführen, um Interaktivität hinzuzufügen oder den Seiteninhalt dynamisch zu aktualisieren.

Browser senden auch weitere HTTP-Anfragen für alle eingebetteten Ressourcen innerhalb des HTML-Dokuments, wie Bilder, CSS-Dateien, JavaScript-Dateien oder andere verlinkte Inhalte. Jede dieser Ressourcen benötigt einen separaten HTTP-Anfrage- und Antwort-Zyklus.

Browser-Funktionen und HTTP-Anfragen

Moderne Webbrowser haben viele Funktionen, die die HTTP-Kommunikation optimieren:

1. Caching: Browser können kürzlich abgerufene Ressourcen in einem lokalen Cache speichern. Wenn dieselbe Ressource erneut benötigt wird, kann der Browser sie aus dem Cache bereitstellen, anstatt eine weitere HTTP-Anfrage zu senden. Dies reduziert den Netzwerkverkehr und lässt Seiten schneller laden.

2. Bedingte Anfragen: Browser können bedingte HTTP-Anfragen senden, die Header wie "If-Modified-Since" oder "If-None-Match" enthalten. Diese ermöglichen es dem Server, nur dann eine vollständige Antwort zu senden, wenn die Ressource seit der letzten Anfrage geändert wurde, was Bandbreite spart, wenn die Ressource unverändert ist.

3. Verschiedene Anfragemethoden: Während die meisten Browser-Anfragen die GET-Methode verwenden, können Browser andere Arten von Anfragen basierend auf Benutzeraktionen senden. Zum Beispiel kann das Absenden eines Formulars eine POST-Anfrage senden, und einige AJAX-Interaktionen können PUT, DELETE oder andere Methoden verwenden.

4. Parallele Anfragen: Moderne Browser können mehrere HTTP-Anfragen parallel senden, was ein schnelleres Laden von Seiten mit vielen Ressourcen ermöglicht. Es gibt jedoch Grenzen für die Anzahl gleichzeitiger Verbindungen, die ein Browser zu einem einzelnen Server herstellt, um eine Überlastung des Servers zu vermeiden.

5. Sicherheitsfunktionen: Browser haben integrierte Sicherheitsfunktionen im Zusammenhang mit HTTP, wie zum Beispiel das Blockieren von Mixed Content (HTTP-Ressourcen auf HTTPS-Seiten), die Durchsetzung von CORS-Richtlinien (Cross-Origin Resource Sharing) und den Umgang mit Cookies und anderen Authentifizierungsmechanismen.

Arten von Statuscodes

HTTP-Statuscodes werden in fünf Klassen eingeteilt, wobei jede Klasse eine bestimmte Art von Antwort darstellt:

1. 1xx (Informativ): Diese Statuscodes zeigen an, dass die Anfrage empfangen wurde und der Prozess fortgesetzt wird. Der Client kann eine endgültige Antwort erwarten, sobald die Anfrageverarbeitung abgeschlossen ist. Ein Beispiel ist 100 Continue, was bedeutet, dass der Server die Request-Header erhalten hat und der Client den Request-Body senden sollte.

2. 2xx (Erfolg): Diese Statuscodes bedeuten, dass die Anfrage erfolgreich vom Server empfangen, verstanden und akzeptiert wurde. Der häufigste Code in dieser Klasse ist 200 OK, der zeigt, dass die Anfrage erfolgreich war.

3. 3xx (Umleitung): Diese Statuscodes zeigen an, dass weitere Maßnahmen vom Client ergriffen werden müssen, um die Anfrage abzuschließen. Dies beinhaltet normalerweise die Umleitung des Clients zu einer anderen URL. Zum Beispiel bedeutet 301 Moved Permanently, dass die angeforderte Ressource dauerhaft zu einer neuen URL verschoben wurde und der Client diese neue URL für zukünftige Anfragen verwenden sollte.

4. 4xx (Client-Fehler): Diese Statuscodes werden verwendet, wenn die Anfrage eine fehlerhafte Syntax enthält oder aufgrund eines clientseitigen Problems nicht erfüllt werden kann. Der bekannte 404 Not Found-Code gehört zu dieser Klasse und zeigt an, dass der Server die angeforderte Ressource nicht finden konnte.

5. 5xx (Server-Fehler): Diese Statuscodes bedeuten, dass der Server eine gültige Anfrage nicht erfüllen konnte. Dies zeigt normalerweise ein Problem mit dem Server selbst an. Der häufigste Code in dieser Klasse ist 500 Internal Server Error, eine allgemeine Antwort, wenn der Server auf eine unerwartete Bedingung stößt, die ihn daran hindert, die Anfrage zu erfüllen.

Häufige Statuscodes

Obwohl es viele HTTP-Statuscodes gibt, sind hier einige der häufigsten:

• 200 OK: Die Anfrage war erfolgreich. Dies ist die Standardantwort für erfolgreiche HTTP-Anfragen.

• 201 Created: Die Anfrage wurde erfüllt und eine neue Ressource wurde als Ergebnis erstellt. Dies ist typischerweise die Antwort, die nach einer POST-Anfrage gesendet wird.

• 301 Moved Permanently: Die angeforderte Ressource wurde dauerhaft zu einer neuen URL verschoben. Zukünftige Verweise auf diese Ressource sollten die zurückgegebene URL verwenden.

• 400 Bad Request: Der Server kann die Anfrage aufgrund eines Client-Fehlers nicht verarbeiten, wie zum Beispiel einer fehlerhaften Anfrage-Syntax.

• 401 Unauthorized: Die Anfrage erfordert eine Benutzerauthentifizierung. Der Client kann die Anfrage mit einem geeigneten Authorization-Header wiederholen.

• 403 Forbidden: Der Server hat die Anfrage verstanden, weigert sich aber, sie zu autorisieren. Dieser Status ist ähnlich wie 401, wird aber verwendet, wenn Authentifizierung nicht hilft.

• 404 Not Found: Der Server kann die angeforderte Ressource nicht finden. Dies kann an einer falschen URL oder einer gelöschten Ressource liegen.

• 500 Internal Server Error: Der Server ist auf eine unerwartete Bedingung gestoßen, die ihn daran gehindert hat, die Anfrage zu erfüllen. Dies ist eine allgemeine Antwort.

• 502 Bad Gateway: Der Server hat beim Agieren als Gateway oder Proxy eine ungültige Antwort von einem Upstream-Server erhalten, auf den er zugreifen musste, um die Anfrage abzuschließen.

• 503 Service Unavailable: Der Server kann die Anfrage derzeit aufgrund einer vorübergehenden Überlastung oder geplanter Wartung nicht bearbeiten. Diese Bedingung ist normalerweise vorübergehend.

Das Verständnis dieser Statuscodes kann beim Beheben von Problemen und beim Umgang mit verschiedenen Situationen in Ihren Webanwendungen sehr helfen. Beim Entwerfen von APIs ist es wichtig, die richtigen Statuscodes zu verwenden, um das Ergebnis der Anfrage eines Clients klar zu kommunizieren. Dies macht Ihre API verständlicher und für andere Entwickler einfacher zu nutzen.

Wenn ein Client eine HTTP-Anfrage an einen Server sendet, öffnet er eine TCP-Verbindung. Der Server gibt dann eine Antwort zurück, die einen HTTP-Statuscode enthält, der die vom Browser auszuführendeAktion angibt. Die Antwortdaten werden im Body der HTTP-Anfrage gespeichert, und der Content-Length-Header gibt die Größe dieser Daten an. Verschiedene HTTP-Methoden wie GET und PUT werden verwendet, um die vom Server auszuführende Aktion anzuzeigen. Während GET-Anfragen zum Abrufen von Daten verwendet werden, sind PUT-Anfragen idempotent und können zum Aktualisieren oder Erstellen von Ressourcen auf dem Server verwendet werden.

Wichtigkeit der Überwachung

Die Überwachung von HTTP-Anfragen ist wichtig, um sicherzustellen, dass Ihr Webservice gut funktioniert und Client-Anfragen erfüllen kann. Durch die Verfolgung von HTTP-Anfragen und -Antworten können Sie schnell Probleme finden und beheben, die auftreten können. Die Überwachung hilft Ihnen, die Gesundheit und Performance Ihrer Webanwendung zu erhalten und ein besseres Benutzererlebnis für Ihre Clients zu bieten.

Verwendung von Uptimia zur Überwachung

Uptimia ist ein nützliches Tool zur Überwachung von HTTP-Anfragen. Es ermöglicht Ihnen, einzelne HTTP-Request-Monitore einzurichten, die detaillierte Antwortdaten aufzeichnen. Mit Uptimia können Sie:

• Die HTTP-Anfragemethode (GET, POST, PUT, DELETE usw.) für Ihren Monitor auswählen
• Die URL angeben, die Sie überwachen möchten
• Das Testintervall wählen, in dem der Monitor ausgeführt wird
• Die Teststandorte auswählen, von denen die HTTP-Anfragen gesendet werden

Sie können auch erweiterte Request-Einstellungen wie Header, Query-Parameter, Cookies und Request-Body konfigurieren. Diese Flexibilität ermöglicht es Ihnen, reale Szenarien zu simulieren und Ihren Webservice gründlich zu testen. Sie können hier mehr über Website-Monitoring lesen.

Einrichten von Benachrichtigungen

Um Probleme schnell zu finden und zu beheben, ist es wichtig, Benachrichtigungen in Ihrem Überwachungssystem einzurichten. Mit Uptimia können Sie Benachrichtigungen erstellen, die ausgelöst werden, wenn bestimmte Bedingungen erfüllt sind, wie zum Beispiel:

• HTTP-Antwortstatuscodes im Bereich 4xx (Client-Fehler) oder 5xx (Server-Fehler)
• Antwortzeit überschreitet einen festgelegten Schwellenwert
• Unerwarteter Inhalt im Response-Body
• SSL/TLS-Zertifikatsablauf oder Validierungsfehler

Durch das Einrichten von Benachrichtigungen können Sie sicherstellen, dass Sie schnell informiert werden, wenn Probleme auftreten, sodass Sie diese zeitnah beheben können. Dies hilft, Ausfallzeiten zu minimieren und eine hohe Servicequalität für Ihre Benutzer aufrechtzuerhalten.

Die Überwachung von HTTP-Anfragen ist nicht nur wichtig, um Probleme zu finden und zu beheben, sondern auch, um Erkenntnisse über die Performance und Nutzungsmuster Ihrer Webanwendung zu gewinnen. Durch die Analyse der von Ihrem Überwachungstool gesammelten Daten können Sie fundierte Entscheidungen zur Optimierung Ihrer Anwendung treffen, wie zum Beispiel:

• Finden und Beseitigen von Performance-Engpässen
• Skalierung der Infrastruktur zur Bewältigung erhöhten Traffics
• Verbesserung von Caching-Strategien zur Reduzierung der Antwortzeiten
• Optimierung von Datenbankabfragen oder API-Aufrufen