Sie öffnen eine Webseite im Browser, klicken auf einen Link, laden ein Bild oder senden ein Formular ab. Auf dem Bildschirm wirkt das selbstverständlich: Inhalte erscheinen, ein Login wird geprüft, ein Warenkorb aktualisiert sich oder eine Fehlermeldung taucht auf. Im Hintergrund passiert dabei jedoch nichts Magisches.
Der Browser sendet über HTTP oder HTTPS Anfragen an einen Webserver und erhält Antworten zurück. Diese Antworten können die angeforderten Daten enthalten, auf eine andere Adresse verweisen oder einen Fehler melden. Genau deshalb begegnen Begriffe wie Request, Response, 404, 500, Header, Cookie oder Cache nicht nur Fachleuten, sondern auch Nutzern, Betreibern von Websites und Menschen, die Fehlermeldungen in Tools oder Protokollen verstehen möchten.
HTTP steht für Hypertext Transfer Protocol und ist ein Protokoll, mit dem Browser, Apps oder andere Clients Daten von Webservern anfordern und Antworten erhalten. Es beschreibt also eine grundlegende Form der Webkommunikation: Ein Client fragt etwas an, ein Server antwortet.
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten
Inhaltsverzeichnis
- Vom Klick zur Serverantwort: Was HTTP im Web konkret macht
- HTTP-Methoden und Statuscodes: Was eine Anfrage tun soll und wie der Server antwortet
- HTTP, HTTPS, Header, Cookies und Cache im Zusammenhang verstehen
- HTTP und HTTPS: Übertragung und verschlüsselte Verbindung
- Header: Zusatzinformationen zur Anfrage oder Antwort
- Cookies: Kleine Speicherinformationen für Sitzungen und Einstellungen
- Cache: Schneller laden, aber manchmal alte Inhalte sehen
- Weiterleitungen: Wenn die Antwort auf eine andere Adresse zeigt
- FAQ zu HTTP
Vom Klick zur Serverantwort: Was HTTP im Web konkret macht
Wenn eine Webseite geöffnet, ein Produktbild geladen oder ein Kontaktformular abgeschickt wird, sieht das im Browser wie eine direkte Handlung aus. Technisch beginnt dabei eine geordnete Kommunikation zwischen einem Client und einem Webserver. Der Client stellt eine Anfrage, der Server verarbeitet sie und sendet eine Antwort zurück.
HTTP ist dabei nicht mit dem gesamten Internet gleichzusetzen. Das Internet umfasst viele technische Grundlagen und Dienste. HTTP ist ein Protokoll für die Webübertragung und verwandte Anwendungsfälle, etwa wenn eine App Daten von einem Webdienst abruft. Es beschreibt nicht die gesamte Netzwerktechnik im Hintergrund, sondern die Kommunikation auf Anwendungsebene: Anfrage und Antwort zwischen Client und Server.
Client und Server: Wer fragt, wer antwortet?
Der Client ist die Seite, die etwas anfragt. In vielen Fällen ist das ein Webbrowser wie Chrome, Firefox, Safari oder Edge. Ein Client kann aber auch eine mobile App, ein Programm auf einem Computer, ein Shop-System oder ein anderes technisches Werkzeug sein, das Daten aus dem Web benötigt. Entscheidend ist nicht die Oberfläche, sondern die Rolle: Der Client startet die Kommunikation.
Der Server ist das System, das auf solche Anfragen reagiert. Er stellt Ressourcen bereit, zum Beispiel HTML-Seiten, Bilder, Stylesheets, JavaScript-Dateien, PDFs oder strukturierte Daten. Der Server kann eine Datei direkt ausliefern, eine Anwendung ausführen, eine Anmeldung prüfen oder entscheiden, dass die angefragte Ressource nicht verfügbar ist.
Der Begriff „Server“ meint dabei nicht zwingend einen einzelnen sichtbaren Rechner. Hinter einer Website können mehrere Systeme, Zwischenschichten oder Dienste stehen. Für das Grundverständnis von HTTP reicht jedoch die einfache Rollenverteilung: Der Client fragt an, der Server antwortet.
Request und Response: Anfrage und Antwort im Web
Eine HTTP-Anfrage heißt Request. Sie enthält unter anderem die Information, welche Ressource der Client haben möchte. Wird im Browser die Adresse /kontakt aufgerufen, fragt der Browser sinngemäß: „Bitte liefere mir die Kontaktseite unter dieser Adresse.“ Lädt die Seite zusätzlich ein Logo, ein Hintergrundbild oder eine Schriftart, entstehen weitere Anfragen für diese einzelnen Bestandteile.
Eine HTTP-Antwort heißt Response. Sie ist die Reaktion des Servers auf den Request. Im einfachsten Fall enthält die Response die angeforderten Daten, etwa den HTML-Code der Kontaktseite oder die Bilddatei für ein Produktfoto. Die Antwort kann aber auch mitteilen, dass die Ressource nicht gefunden wurde, dass eine Anmeldung erforderlich ist oder dass der Client eine andere Adresse aufrufen soll.
Damit lässt sich ein alltäglicher Ablauf gut nachvollziehen: Ein Klick auf einen Link zur Kontaktseite führt zu einem Request an den Server. Der Server prüft, ob es diese Seite gibt und ob sie ausgeliefert werden kann. Anschließend sendet er eine Response zurück. Enthält diese Antwort die Kontaktseite, baut der Browser daraus die sichtbare Darstellung auf. Gibt es die Seite unter der angefragten Adresse nicht, kann der Server stattdessen einen Fehler melden.
- Client: Browser, App oder anderes Programm, das eine Ressource anfordert.
- Server: System, das Ressourcen wie Webseiten, Bilder, Dateien oder Daten bereitstellt.
- Request: die Anfrage des Clients, zum Beispiel nach einer Seite, einem Bild oder beim Absenden eines Formulars.
- Response: die Antwort des Servers mit den angeforderten Daten, einem Fehlerhinweis oder einer Weiterleitung.
Auch Formulare und Bilder folgen diesem Muster
HTTP betrifft nicht nur das Öffnen einer vollständigen Webseite. Wenn ein Bild auf einer Seite erscheint, wurde es zuvor als eigene Ressource angefragt. Wenn ein Formular abgesendet wird, übermittelt der Browser die eingegebenen Daten an den Server. Der Server kann diese Daten verarbeiten, speichern, prüfen oder zurückweisen und danach eine passende Antwort senden.
Gerade deshalb tauchen HTTP-Begriffe bei sehr unterschiedlichen Websituationen auf. Eine Seite kann normal laden, während ein einzelnes Bild fehlt. Ein Formular kann sichtbar sein, aber nach dem Absenden eine Fehlermeldung erzeugen. Ein Link kann nicht den erwarteten Inhalt liefern, sondern auf eine andere Adresse führen. In allen Fällen hilft das Grundmuster aus Client, Server, Request und Response dabei, die sichtbare Situation präziser einzuordnen.
HTTP macht Webkommunikation nachvollziehbar. Jede sichtbare Webaktion lässt sich auf eine oder mehrere Anfragen und Antworten zurückführen. Wer dieses Prinzip versteht, kann spätere Begriffe wie Methoden, Statuscodes, Header, Cookies, Cache oder Weiterleitungen besser einordnen, weil sie alle an dieser Kommunikation zwischen Client und Server ansetzen.
HTTP-Methoden und Statuscodes: Was eine Anfrage tun soll und wie der Server antwortet
Eine HTTP-Anfrage besteht nicht nur aus der Adresse, die im Browser oder in einer App aufgerufen wird. Sie enthält auch eine Information darüber, was mit der angefragten Ressource geschehen soll. Genau dafür gibt es HTTP-Methoden. Sie beschreiben aus Sicht des Clients die Absicht der Anfrage: Daten abrufen, Daten senden, etwas ändern oder etwas löschen.
Für normale Nutzer bleibt diese Ebene meist unsichtbar. Wer eine Seite öffnet, sieht nicht ausdrücklich, dass der Browser eine bestimmte Methode verwendet. Bei Formularen, Logins, Shop-Bestellungen, Schnittstellen oder Fehlersuchen wird die Unterscheidung aber wichtig, weil nicht jede Anfrage dasselbe bedeutet und nicht jede Serverantwort denselben Befund liefert.
HTTP-Methoden sind keine sichtbaren Schaltflächen, sondern technische Verben innerhalb einer Anfrage. Sie helfen dem Server zu verstehen, ob der Client nur etwas lesen möchte oder ob Daten übertragen werden, die eine Änderung auslösen können.
GETwird verwendet, um Daten abzurufen. Typisch ist der Aufruf einer Webseite, eines Bildes, einer Datei oder einer Suchergebnisansicht. Der Client fragt: „Bitte liefere mir diese Ressource.“POSTdient häufig dazu, Daten an den Server zu senden. Das passiert etwa bei Kontaktformularen, Logins, Kommentaren, Bestellungen oder beim Absenden von Such- und Filterdaten, wenn diese nicht einfach nur über die Adresse übergeben werden sollen.PUTundPATCHwerden vor allem bei Anwendungen und Schnittstellen genutzt, wenn bestehende Daten geändert werden. Vereinfacht gesagt stehtPUTeher für ein vollständiges Ersetzen,PATCHeher für eine teilweise Änderung. Wie genau eine Anwendung das auslegt, hängt jedoch von ihrer Umsetzung ab.DELETEbeschreibt eine Anfrage zum Löschen einer Ressource. Das bedeutet nicht automatisch, dass tatsächlich etwas gelöscht wird: Die Anwendung prüft in der Regel Berechtigungen, Regeln und den aktuellen Zustand, bevor sie eine solche Anfrage ausführt oder ablehnt.
Diese Methoden sagen etwas über die beabsichtigte Aktion aus, nicht über den Erfolg. Ob der Server die Anfrage versteht, erlaubt, ausführt oder ablehnt, zeigt sich erst in der Antwort. Ein Formular kann korrekt per POST gesendet werden und trotzdem scheitern, etwa weil Pflichtfelder fehlen, eine Anmeldung abgelaufen ist oder der Server intern einen Fehler hat.
Statuscodes: Die Kurzmeldung des Servers
Zu jeder HTTP-Response gehört ein Statuscode. Er ist eine kurze, standardisierte Zahl, mit der der Server grob mitteilt, wie die Anfrage ausgegangen ist. Der Code ersetzt nicht den eigentlichen Inhalt der Antwort, liefert aber eine wichtige Einordnung: erfolgreich, weitergeleitet, problematisch angefragt, nicht erlaubt oder serverseitig fehlgeschlagen.
200bedeutet grundsätzlich, dass die Anfrage erfolgreich beantwortet wurde. Bei einer Webseite kann das die gelieferte HTML-Seite sein, bei einer Datei der Dateiinhalt, bei einer Schnittstelle eine Datenantwort.301steht für eine dauerhafte Weiterleitung. Der Server teilt mit, dass die Ressource künftig unter einer anderen Adresse erreichbar ist.302beschreibt eine vorübergehende Weiterleitung. Der Client soll aktuell einer anderen Adresse folgen, ohne dass damit zwingend eine dauerhafte Änderung gemeint ist.400weist auf eine fehlerhafte Anfrage hin. Der Server kann die Anfrage in dieser Form nicht sinnvoll verarbeiten, etwa weil Angaben fehlen oder das Format nicht passt.401bedeutet, dass eine Authentifizierung fehlt oder nicht gültig ist. Häufig ist also eine Anmeldung, ein Token oder eine andere Form der Identifikation erforderlich.403heißt, dass der Zugriff verweigert wird. Der Server versteht die Anfrage, erlaubt sie aber nicht. Das kann auch dann gelten, wenn eine Person angemeldet ist, aber nicht die nötigen Rechte besitzt.404bedeutet, dass die angefragte Ressource nicht gefunden wurde. Der Server kann erreichbar sein, aber genau diese Seite, Datei oder Adresse existiert aus seiner Sicht nicht.500steht für einen internen Serverfehler. Die Anfrage erreicht den Server, dieser kann aber nicht korrekt antworten. Die Ursache liegt häufig in der Anwendung, Konfiguration oder Verarbeitung auf Serverseite.503bedeutet, dass der Dienst vorübergehend nicht verfügbar ist. Das kann bei Wartung, Überlastung oder einem nicht erreichbaren nachgelagerten Dienst auftreten.
Solche Codes erscheinen nicht nur in technischen Prüfwerkzeugen. Sie können im Browser sichtbar werden, in Verwaltungsbereichen von Websites, in Shop-Systemen, in API-Tools oder in Serverprotokollen. Manchmal zeigt die Oberfläche statt der Zahl eine verständliche Meldung an, etwa „Seite nicht gefunden“ oder „Dienst vorübergehend nicht verfügbar“. In der technischen Antwort steckt dennoch ein Statuscode, der die Meldung einordnet.
Wichtig ist die Trennung zwischen Bedeutung und Ursache. Ein 404 sagt aus, dass die angefragte Ressource nicht gefunden wurde, aber noch nicht, warum sie fehlt. Ein 500 zeigt einen serverseitigen Fehler an, verrät aber nicht automatisch, welche Komponente ihn ausgelöst hat. Genau deshalb ist die vorsichtige Deutung hilfreicher als eine vorschnelle Diagnose.
Typische Beobachtungen richtig einordnen
Die folgende Übersicht verbindet sichtbare Webprobleme mit dem, was auf HTTP-Ebene häufig passiert. Sie ist keine Reparaturanleitung und ersetzt keine genaue Prüfung der jeweiligen Website. Sie hilft aber dabei, Symptome sauberer zu benennen und die nächste naheliegende Prüfung einzugrenzen.
| Was Sie sehen | Was auf HTTP-Ebene meist passiert | Woran Sie den Unterschied erkennen | Was sinnvoll als Nächstes geprüft wird |
|---|---|---|---|
| Sie sehen eine 404-Seite oder eine Meldung wie „Seite nicht gefunden“. | Der Client hat eine bestimmte Adresse angefragt, aber der Server findet die passende Ressource nicht. Der Server selbst kann dabei grundsätzlich erreichbar sein. | Die übrige Website kann weiterhin funktionieren. Oft betrifft es nur eine konkrete Unterseite, ein Bild, eine Datei oder einen alten Link. | Adresse auf Tippfehler prüfen, über die Navigation zur Seite gehen, alte Lesezeichen hinterfragen oder den Seitenbetreiber auf den nicht gefundenen Link hinweisen. |
| Der Browser meldet zu viele Weiterleitungen oder lädt immer wieder dieselbe Seite. | Der Server antwortet nicht mit dem eigentlichen Inhalt, sondern mit Weiterleitungen. Folgen mehrere 301– oder 302-Antworten im Kreis aufeinander, bricht der Browser irgendwann ab. |
Die sichtbare URL kann mehrfach wechseln oder zwischen Varianten springen, etwa mit und ohne Schrägstrich, mit und ohne Subdomain oder zwischen zwei Anmeldezuständen. | Prüfen, ob die Adresse korrekt ist, ob eine Anmeldung erwartet wird und ob das Problem auch nach dem Leeren betroffener Website-Daten weiter besteht. Bei fremden Seiten ist eine Meldung an den Betreiber sinnvoll. |
| Statt einer Seite erscheint ein 500-Fehler oder eine allgemeine Serverfehlermeldung. | Die Anfrage erreicht den Server, aber dieser kann intern keine gültige Antwort erzeugen. Der Befund spricht nicht dafür, dass der Nutzer die Seite falsch bedient hat. | Der Fehler tritt oft unabhängig vom Browser auf und kann bestimmte Aktionen betreffen, etwa das Speichern eines Formulars, das Öffnen einer Produktseite oder den Aufruf eines Verwaltungsbereichs. | Vorgang später erneut versuchen, Eingaben nicht unnötig mehrfach absenden und bei anhaltendem Fehler den Betreiber mit Zeitpunkt, betroffener Adresse und sichtbarer Meldung informieren. |
| Eine eigentlich verschlüsselte Seite zeigt Warnungen oder lädt Bilder, Skripte oder Stile nicht vollständig. | Die Hauptseite wird über HTTPS geladen, einzelne Inhalte werden aber über unverschlüsseltes HTTP angefordert. Browser können solche gemischten Inhalte blockieren oder deutlich markieren. | Die Adresse der Seite beginnt mit HTTPS, trotzdem fehlen einzelne Elemente oder der Browser weist auf unsichere beziehungsweise blockierte Inhalte hin. | Bei eigener Website sollten eingebundene Ressourcen auf HTTPS-Adressen geprüft werden. Als Nutzer ist Zurückhaltung bei Formularen sinnvoll, wenn die Seite sichtbar fehlerhaft oder unvollständig lädt. |
| Ein Formular reagiert nicht wie erwartet, sendet scheinbar nicht oder zeigt nach dem Absenden eine Fehlermeldung. | Häufig wird eine POST-Anfrage gesendet. Die Antwort kann aber unterschiedlich ausfallen: fehlende Pflichtdaten, fehlende Authentifizierung, verweigerter Zugriff, Weiterleitung oder ein Serverfehler. |
Eine Login-Aufforderung deutet eher auf 401 oder einen abgelaufenen Sitzungszustand hin, eine Zugriffsverweigerung eher auf 403, eine allgemeine Fehlermeldung eher auf ein serverseitiges Problem. Manchmal bleibt die Seite auch wegen einer blockierten Antwort unverändert. |
Eingaben kontrollieren, Anmeldung prüfen, nicht mehrfach hektisch absenden und bei Bestellungen oder Zahlungen erst klären, ob der Vorgang bereits verarbeitet wurde. |
| Der Browser zeigt weiterhin eine alte Version einer Seite, obwohl sich der Inhalt geändert haben soll. | Der Client kann eine gespeicherte Antwort aus dem Cache verwenden, statt die Ressource vollständig neu vom Server zu laden. Cache-Hinweise werden über HTTP-Header gesteuert. | Auf einem anderen Gerät, in einem anderen Browser oder nach dem gezielten Neuladen erscheint möglicherweise bereits die neue Version. Einzelne Bilder oder Stildateien können länger alt bleiben als der Text. | Seite gezielt neu laden, Browsercache für die betreffende Seite leeren oder auf einem zweiten Gerät vergleichen. Bei eigener Website sollte geprüft werden, ob Cache-Regeln zur gewünschten Aktualisierung passen. |
| Ein API-Tool zeigt einen Statuscode, der nicht zum Inhalt der Antwort zu passen scheint. | Statuscode und Antwortinhalt müssen zusammen betrachtet werden. Es kann vorkommen, dass ein Fehlertext mit 200 zurückkommt oder eine eigentlich erfolgreiche Aktion mit einem Fehlercode beantwortet wird. |
Der Code wirkt erfolgreich, aber der Text beschreibt einen Fehler; oder der Code wirkt fehlerhaft, obwohl im Inhalt eine erfolgreiche Verarbeitung behauptet wird. Besonders bei Schnittstellen ist diese Abweichung für die Auswertung wichtig. | Antwortcode, Antworttext und angefragte Methode gemeinsam prüfen. Bei unklaren Schnittstellen sollte dokumentiert werden, welche Anfrage gestellt wurde und welche widersprüchliche Antwort zurückkam. |
Die Tabelle zeigt auch, warum ein HTTP-Befund selten allein genügt. Ein Statuscode ist ein starkes Signal, aber er steht immer im Zusammenhang mit der angefragten Adresse, der verwendeten Methode, dem Anmeldezustand, möglichen Weiterleitungen und dem Inhalt der Antwort. Erst diese Kombination macht aus einer Zahl eine brauchbare technische Einordnung.
Für die Praxis ist daher eine einfache Lesart hilfreich: Die Methode beschreibt, was der Client versucht hat. Der Statuscode beschreibt, wie der Server darauf grundsätzlich reagiert hat. Die sichtbare Meldung, die URL im Browser und der Inhalt der Antwort helfen anschließend dabei, den Unterschied zwischen einem fehlenden Dokument, einer verweigerten Anfrage, einer Weiterleitung, einem Cache-Effekt und einem serverseitigen Fehler zu erkennen.
HTTP, HTTPS, Header, Cookies und Cache im Zusammenhang verstehen
HTTP beschreibt die Webübertragung zwischen Client und Server: eine Anfrage und eine Antwort. In der Praxis tauchen daneben mehrere Begriffe auf, die diese Kommunikation ergänzen oder beeinflussen. Besonders häufig sind HTTPS, Header, Cookies, Cache und Weiterleitungen.
HTTP und HTTPS: Übertragung und verschlüsselte Verbindung
HTTPS ist HTTP über eine verschlüsselte TLS-Verbindung. Der grundlegende Ablauf aus Request und Response bleibt erhalten, die Verbindung wird jedoch zusätzlich abgesichert. Das ist wichtig, damit übertragene Daten auf dem Weg zwischen Client und Server nicht ohne Weiteres mitgelesen oder verändert werden können.
HTTPS beweist allerdings nicht automatisch, dass eine Website seriös, rechtlich unbedenklich oder inhaltlich vertrauenswürdig ist. Es sagt in erster Linie etwas über die abgesicherte Verbindung aus, nicht über die Absichten des Betreibers oder die Qualität der Inhalte. Eine verschlüsselte Verbindung ist deshalb ein wichtiger Sicherheitsbaustein, aber kein allgemeiner Vertrauensnachweis.
Header: Zusatzinformationen zur Anfrage oder Antwort
HTTP-Header sind zusätzliche Informationen, die mit einem Request oder einer Response übertragen werden. Sie können zum Beispiel angeben, welchen Inhaltstyp eine Antwort hat, welche Sprache bevorzugt wird, ob eine Antwort zwischengespeichert werden darf, wohin eine Weiterleitung zeigt oder in welchem Authentifizierungskontext eine Anfrage steht.
Header sind oft der Grund, warum zwei äußerlich ähnliche Aufrufe unterschiedlich reagieren. Eine Seite kann je nach Anmeldung, Sprache, Cache-Regel oder Weiterleitungsziel eine andere Antwort liefern. Für Einsteiger ist dabei weniger der einzelne Header-Name wichtig als das Prinzip: Neben der eigentlichen Adresse werden weitere Informationen mitgeschickt, die die Antwort beeinflussen können.
Cookies: Kleine Speicherinformationen für Sitzungen und Einstellungen
Cookies sind kleine Speicherinformationen im Browser, die durch eine Website veranlasst werden können. Sie werden häufig genutzt, um Sitzungen, Logins, Warenkörbe oder Einstellungen wiederzuerkennen. Dadurch muss eine Website nicht bei jedem Seitenaufruf vollständig neu herausfinden, ob ein Nutzer bereits angemeldet ist oder welche Auswahl zuvor getroffen wurde.
Bei HTTP-Problemen können Cookies deshalb eine Rolle spielen, wenn eine Anmeldung nicht erkannt wird, ein Warenkorb leer erscheint oder eine Seite zwischen verschiedenen Zuständen wechselt. Das bedeutet nicht automatisch, dass Cookies die Ursache sind, aber sie gehören zum Kontext vieler Webantworten.
Cache: Schneller laden, aber manchmal alte Inhalte sehen
Ein Cache speichert Antworten oder Teile davon zwischen, damit Inhalte schneller laden und nicht bei jedem Aufruf vollständig neu übertragen werden müssen. Das kann im Browser, auf dem Weg zur Website oder auf Serverseite passieren. Gesteuert wird dieses Verhalten häufig über HTTP-Header.
Der Vorteil ist Geschwindigkeit. Der Nachteil zeigt sich, wenn eine alte gespeicherte Antwort angezeigt wird, obwohl sich die Seite bereits geändert hat. Dann wirkt es so, als sei eine Aktualisierung nicht angekommen, obwohl möglicherweise nur noch eine ältere Version aus dem Cache verwendet wird.
Weiterleitungen: Wenn die Antwort auf eine andere Adresse zeigt
Eine Weiterleitung bedeutet, dass der Server nicht den angefragten Inhalt liefert, sondern dem Client eine andere Adresse nennt. Häufig geschieht das mit Statuscodes wie 301 oder 302. Solche Weiterleitungen sind normal, etwa wenn eine Seite umgezogen ist, eine Adresse vereinheitlicht wird oder nach einem Login ein anderer Bereich geöffnet werden soll.
Problematisch wird es, wenn Weiterleitungen im Kreis laufen oder auf ein unerwartetes Ziel führen. Dann erscheint im Browser keine gewünschte Seite, sondern eine Meldung über zu viele Weiterleitungen oder ein wiederholter Wechsel zwischen Adressen.
FAQ zu HTTP
Was bedeutet HTTP?
HTTP steht für Hypertext Transfer Protocol. Es ist ein Protokoll, mit dem Browser, Apps oder andere Clients Daten von Webservern anfordern und Antworten erhalten.
Was ist ein HTTP-Request?
Ein HTTP-Request ist die Anfrage eines Clients an einen Server. Er kann zum Beispiel eine Webseite, ein Bild, eine Datei oder die Verarbeitung von Formulardaten betreffen.
Was ist ein HTTP-Statuscode?
Ein HTTP-Statuscode ist eine Zahl in der Serverantwort. Sie ordnet grob ein, ob eine Anfrage erfolgreich war, weitergeleitet wurde, ein Problem mit der Anfrage bestand oder der Server nicht korrekt antworten konnte.
Was bedeutet 404?
404 bedeutet, dass die angefragte Ressource nicht gefunden wurde. Der Server kann erreichbar sein, findet aber die konkrete Seite, Datei oder Adresse nicht.
Was bedeutet 500?
500 steht für einen internen Serverfehler. Die Anfrage erreicht den Server, aber dieser kann keine korrekte Antwort erzeugen.
Was ist der Unterschied zwischen HTTP und HTTPS?
HTTP beschreibt die Webkommunikation aus Anfrage und Antwort. HTTPS nutzt HTTP über eine verschlüsselte TLS-Verbindung. Dadurch wird die Verbindung abgesichert, ohne dass damit automatisch die Seriosität einer Website bewiesen wäre.
Was sind HTTP-Header?
HTTP-Header sind zusätzliche Informationen in einer Anfrage oder Antwort. Sie können zum Beispiel Inhaltstyp, Sprache, Cache-Hinweise, Weiterleitungsziele oder Angaben zum Authentifizierungskontext betreffen.
Warum leitet eine Webseite weiter?
Eine Webseite leitet weiter, wenn der Server dem Client mitteilt, dass die angefragte Ressource unter einer anderen Adresse erreichbar ist oder aktuell ein anderer Zielort genutzt werden soll. Häufig geschieht das mit 301 oder 302.
HTTP ist der Grundmechanismus, mit dem Clients und Webserver im Web miteinander sprechen: Eine Seite, ein Bild, ein Formular oder eine API-Antwort entsteht aus Anfrage und Antwort. Wer Client, Server, Request, Response, Methoden und Statuscodes einordnen kann, versteht viele sichtbare Webprobleme deutlich besser.
HTTPS ergänzt diese Kommunikation um eine verschlüsselte TLS-Verbindung und ist heute für vertrauliche Übertragung wichtig. Für die praktische Deutung bleibt aber entscheidend, die einzelnen Signale sauber zu lesen: Ein 404 weist auf eine nicht gefundene Ressource hin, ein 500 eher auf ein serverseitiges Problem, ein Redirect auf eine andere Adresse und ein Cache manchmal nur auf eine alte gespeicherte Antwort.
Meroth IT-Service ist Ihr lokaler IT-Dienstleister in Frankfurt am Main für kleine Unternehmen, Selbstständige und Privatkunden
Kostenfreie Ersteinschätzung Ihres Anliegens?
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten