Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development
Code

HTTP kurz: HTTP-Nachrichten

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called HTTP Succinctly.
HTTP Succinctly: HTTP Resources
HTTP Succinctly: HTTP Connections

German (Deutsch) translation by Jenyia (you can also view the original English article)

In diesem Kapitel sehen wir uns die Nachrichten an, die in einer HTTP-Transaktion ausgetauscht werden. Wir werden über Nachrichtentypen, HTTP-Header und Statuscodes lernen. Zu verstehen, was sich in einer HTTP-Nachricht befindet, ist für Entwickler, die im Web arbeiten, von entscheidender Bedeutung. Sie können nicht nur bessere Anwendungen erstellen, indem Sie mit den richtigen Nachrichtentypen antworten, sondern Sie können auch Probleme erkennen und Probleme beheben, wenn Webanwendungen nicht funktionieren.

Anfragen und Antworten

Stellen Sie sich vor, Sie gehen zu einem Fremden in einem Flughafen und fragen: "Wissen Sie, wie spät es ist?" Damit der Fremde mit der richtigen Zeit antwortet, müssen ein paar Dinge vorhanden sein.  Zuerst muss der Fremde Ihre Frage verstehen, denn wenn er oder sie kein Englisch kann, kann er oder sie keine Antwort geben. Zweitens benötigt der Fremde Zugang zu einer Uhr oder einem anderen Zeitmessgerät.

Diese Flughafenanalogie ähnelt der Funktionsweise von HTTP. Sie, der Kunde, benötigen eine Ressource von einer anderen Partei (die Ressource ist Information über die Tageszeit). Also, Sie stellen eine Anfrage an die andere Partei mit einer Sprache und Vokabeln, von denen Sie hoffen, dass die andere Partei sie versteht. Wenn die andere Partei Ihre Anfrage versteht und die Ressource verfügbar ist, kann sie antworten. Wenn es die Anfrage versteht, aber nicht über die Ressource verfügt, kann es trotzdem antworten und Ihnen mitteilen, dass es es nicht weiß. Wenn die andere Partei nicht versteht, was Sie sagen, erhalten Sie möglicherweise keine Antwort.

HTTP ist ein Anfrage- und Antwortprotokoll. Ein Client sendet eine HTTP-Anforderung an einen Server mit einer sorgfältig formatierten Nachricht, die der Server versteht. Ein Server antwortet, indem er eine HTTP-Antwort sendet, die der Client versteht. Die Anfrage und die Antwort sind zwei verschiedene Nachrichtentypen, die in einer einzigen HTTP-Transaktion ausgetauscht werden. Die HTTP-Standards definieren, was in diesen Anfrage- und Antwortnachrichten geschieht, damit jeder, der "HTTP" spricht, sich gegenseitig versteht und Ressourcen austauschen kann (oder wenn eine Ressource nicht existiert, kann ein Server trotzdem antworten und Sie wissen lassen).


Eine rohe Anfrage und Antwort

Ein Webbrowser weiß, wie er eine HTTP-Anforderung sendet, indem er eine Netzwerkverbindung zu einem Servercomputer öffnet und eine HTTP-Nachricht als Text sendet. Es gibt nichts Magisches an der Anfrage - es ist nur ein Befehl in reinem ASCII-Text und entsprechend der HTTP-Spezifikation formatiert. Jede Anwendung, die Daten über ein Netzwerk senden kann, kann eine HTTP-Anfrage stellen. Sie können sogar eine manuelle Anfrage mit einer Anwendung wie Telnet von der Kommandozeile aus machen. Eine normale Telnet-Session verbindet sich über Port 23, aber wie wir im ersten Kapitel erfahren haben, ist der Standard-Netzwerkport für HTTP Port 80.

  Die folgende Abbildung ist ein Screenshot einer Telnet-Sitzung, die über Port 80 eine Verbindung zu odecode.de herstellt, eine HTTP-Anforderung sendet und eine HTTP-Antwort empfängt.

Figure 2: Making an HTTP request
Eine HTTP-Anfrage machen

Die Telnet-Session beginnt mit der Eingabe von:

Bitte beachten Sie, dass der Telnet-Client nicht standardmäßig unter Windows 7, Windows Server 2008 R2, Windows Vista oder Windows Server 2008 installiert wird.  Sie können den Client installieren, indem Sie die unter http://technet.microsoft.com/en-us/library/cc771275 (v = ws.10).aspx aufgeführten Schritte ausführen

Dieser Befehl weist das Betriebssystem an, die Telnet-Anwendung zu starten, und teilt der Telnet-Anwendung mit, sich mit Port 80 mit www.odetocode.com zu verbinden.

Sobald Telnet eine Verbindung herstellt, können wir eine HTTP-Anforderungsnachricht eingeben. Die erste Zeile wird erstellt, indem Sie den folgenden Text eingeben und dann die Enter-Taste drücken:

Diese Informationen teilen dem Server mit, dass wir die Ressource "/" (d. h. Die Root-Ressource oder die Homepage) abrufen möchten, und wir werden HTTP 1.1-Funktionen verwenden. Die nächste Zeile, die wir eingeben, lautet:

Diese Host-Information ist eine erforderliche Information in einer HTTP 1.1-Anforderungsnachricht. Der technische Grund dafür besteht darin, Servern zu helfen, die mehrere Websites unterstützen, dh sowohl www.odetocode.com als auch www.odetofood.com können auf demselben Server gehostet werden, und die Host - Informationen in der Nachricht helfen dem Webserver, die Anfrage an die richtige Web-Anwendung.

Nachdem Sie die vorherigen zwei Zeilen eingegeben haben, können Sie die Enter-Taste zweimal drücken, um die Nachricht an den Server zu senden. Was Sie als nächstes im Telnet-Fenster sehen, ist die HTTP-Antwort vom Webserver. Wir werden später detaillierter darauf eingehen, aber die Antwort besagt, dass die Ressource, die wir haben wollen (die Standard-Homepage von www.odetocode.com), verschoben wurde. Es ist auf den Standort odetocode.com umgezogen. Es liegt nun an dem Client, diese Antwortnachricht zu parsen und eine Anfrage an odecodeode.com anstatt an www.odetocode.com zu senden, wenn er die Homepage abrufen möchte. Jeder Webbrowser wird automatisch an den neuen Standort weitergeleitet.

Diese Art von "Weiterleitungen" ist üblich, und in diesem Szenario ist der Grund dafür, sicherzustellen, dass alle Anforderungen für Ressourcen von OdeToCode über ODocode.com und nicht über www.Detocode.com gehen (dies ist eine Suchmaschinenoptimierung, die als URL-Kanonisierung bekannt ist).

Jetzt, da wir eine rohe HTTP-Anfrage und -Reaktion gesehen haben, wollen wir uns auf bestimmte Teile konzentrieren.


HTTP-Anforderungsmethoden

Das GET-Wort, das in die Telnet-Session eingegeben wird, ist eine der primären HTTP-Methoden. Jede Anforderungsnachricht muss eine der HTTP-Methoden enthalten, und die Methode teilt dem Server mit, was die Anforderung ausführen soll. Ein HTTP-GET möchte eine Ressource abrufen, abrufen und abrufen. Sie könnten GET ein Bild  (GET /logo.png) oder eine GET PDF-Datei (GET /documents/report.pdf) oder eine andere besitzt. Eine Liste der häufigsten HTTP-Operatoren wird in der folgenden Tabelle gezeigt.

Methode Beschreibung
GET Abrufen einer Ressource
PUT Speichern Sie eine Ressource
DELETE Entfernen Sie eine Ressource
POST Aktualisieren Sie eine Ressource
HEAD Abrufen der Header für eine Ressource

Von diesen fünf Methoden sind nur zwei die wichtigsten Arbeitspferde des Internets: GET und POST. Ein Webbrowser gibt eine GET-Anforderung aus, wenn er eine Ressource wie eine Seite, ein Bild, ein Video oder ein Dokument abrufen möchte. GET-Anforderungen sind die häufigste Art von Anfrage.

Ein Webbrowser sendet eine POST-Anforderung, wenn Daten an den Server gesendet werden. Wenn Sie beispielsweise auf einer Website wie amazon.com auf "In den Warenkorb legen" klicken, werden Informationen an POST gesendet, was wir kaufen möchten. POST-Anfragen werden normalerweise von einem auf einer Webseite generiert, wie <form>, das Sie mit <input>-Elementen für Adress- und Kreditkarteninformationen ausfüllen.


GET und Sicherheit

Es gibt einen Teil der HTTP-Spezifikation, der über die "sicheren" HTTP-Methoden spricht. Sichere Methoden, wie der Name schon sagt, machen nichts "unsicheres" wie eine Ressource zerstören, eine Kreditkartentransaktion einreichen oder ein Konto löschen. Die GET-Methode ist eine der sicheren Methoden, da sie nur eine Ressource abrufen und den Status der Ressource nicht ändern soll. Wenn Sie eine GET-Anforderung für ein JPG-Bild senden, ändert sich das Bild nicht, es wird nur das Bild zur Anzeige abgerufen. Kurz gesagt, es sollte niemals eine Nebenwirkung auf eine GET-Anfrage geben.

Ein HTTP-POST ist keine sichere Methode. Ein POST ändert normalerweise etwas auf dem Server - er aktualisiert ein Konto, sendet eine Bestellung oder führt eine andere spezielle Operation aus. Webbrowser behandeln GET und POST normalerweise unterschiedlich, da GET sicher ist und POST nicht sicher ist. Es ist in Ordnung, eine Webseite zu aktualisieren, die von einer GET-Anfrage abgerufen wurde - der Web-Browser wird nur die letzte GET-Anfrage erneut ausgeben und alles, was der Server zurücksendet, rendern. Wenn jedoch die Seite, die wir in einem Browser betrachten, die Antwort einer HTTP-POST-Anfrage ist, wird der Browser uns warnen, wenn wir versuchen, die Seite zu aktualisieren. Vielleicht haben Sie diese Arten von Warnungen in Ihrem Webbrowser gesehen.

Figure 3: Refreshing a POST request
Aktualisieren einer POST-Anfrage

Aufgrund dieser Warnungen versuchen viele Webanwendungen immer, den Client das Ergebnis einer GET-Anfrage anzeigen zu lassen. Nachdem ein Benutzer auf eine Schaltfläche geklickt hat, um POST-Informationen an einen Server zu senden (z. B. eine Bestellung abschickt), verarbeitet der Server die Informationen und antwortet mit einer HTTP-Weiterleitung (wie die Weiterleitung im Telnet-Fenster), die den Browser anweist, eine GET andere Ressource abzurufen. Der Browser gibt die GET-Anforderung aus, der Server antwortet mit einer "Vielen Dank für die Bestellung"-Ressource, und dann kann der Benutzer die Seite so oft aktualisieren oder drucken, wie er möchte. Das ist ein gängiges Webdesignmuster, das als POST/Redirect/GET-Muster bekannt ist.

Nun, da wir ein bisschen mehr über POST und GET wissen, wollen wir über einige häufige Szenarien sprechen und sehen, wann wir die verschiedenen Methoden anwenden müssen.


Gemeinsames Szenario-GET

Nehmen wir an, Sie haben eine Seite und möchten, dass der Benutzer auf einen Link klickt, um den ersten Artikel dieser Serie anzuzeigen. In diesem Fall genügt ein einfacher Hyperlink.

Wenn ein Benutzer auf den Hyperlink in einem Browser klickt, gibt der Browser eine GET-Anforderung an die URL aus, die im Attribut href des anchor-Tags angegeben ist. Die Anfrage würde so aussehen:


Szenario-POST

Stellen Sie sich vor, Sie haben eine Seite, auf der der Benutzer Informationen eingeben muss, um ein Konto zu erstellen. Das Ausfüllen von Informationen erfordert <input>-Tags, und wir verschachteln diese Eingaben in einem <form>-Tag und teilen dem Browser mit, wohin die Informationen gesendet werden sollen.

Wenn der Benutzer auf die Senden-Schaltfläche klickt, erkennt der Browser, dass sich die Schaltfläche in einem Formular befindet. Das Formular teilt dem Browser mit, dass die zu verwendende HTTP-Methode POST ist und der Pfad zu POST /account/create lautet. Beachten Sie, dass die Formulareingaben in der HTTP-Nachricht enthalten sind.

Beachten Sie, dass die Formulareingaben in der HTTP-Nachricht enthalten sind. Das ist sehr ähnlich wie Parameter in einer URL angezeigt werden, wie wir im vorherigen Artikel gesehen haben. Es liegt an der Webanwendung, die diese Anforderung empfängt, diese Werte zu analysieren und das Benutzerkonto zu erstellen. Die Anwendung kann dann auf verschiedene Arten antworten.Es gibt jedoch drei allgemeine Antworten:

  1. Reagieren Sie mit HTML und teilen Sie dem Benutzer mit, dass das Konto erstellt wurde. Dadurch wird der Benutzer das Ergebnis einer POST-Anfrage sehen, was zu Problemen führen kann, wenn er die Seite aktualisiert - es könnte versuchen, sie ein zweites Mal zu registrieren!
  2. Reagieren Sie mit einer Umleitungsinstruktion, wie wir sie zuvor gesehen haben, damit der Browser eine sichere GET-Anfrage für eine Seite abgibt, die dem Benutzer mitteilt, dass das Konto erstellt wurde.
  3. Reagieren Sie mit einem Fehler oder leiten Sie auf eine Fehlerseite um. Wir werden uns später ein paar Fehlerszenarien im Buch ansehen.

Formulare und GET-Anfragen

Ein drittes Szenario ist ein Suchszenario. In einem Suchszenario benötigen Sie eine <input>, damit der Benutzer einen Suchbegriff eingeben kann. Es könnte wie folgt aussehen.

Beachten Sie, dass die Methode in diesem Formular GET, nicht POST ist. Das liegt daran, dass eine Suche eine sichere Suchoperation ist, im Gegensatz zur Erstellung eines Kontos oder der Buchung eines Fluges nach Belgien. Der Browser sammelt die Eingaben im Formular und gibt eine GET-Anfrage an den Server aus:

Beachten Sie, anstatt die Eingabewerte in den Nachrichtentext einzufügen, gehen die Eingaben in den Abfragezeichenfolgeabschnitt der URL über. Der Browser sendet eine GET-Anfrage für /search?term=love. Da der Suchbegriff in der URL enthalten ist, kann der Benutzer die URL als Lesezeichen speichern oder den Link kopieren und in einer E-Mail senden. Der Benutzer könnte die Seite auch so oft aktualisieren, wie er möchte, da die GET-Operation für die Suchergebnisse eine sichere Operation ist, die Daten nicht zerstört oder ändert.


Ein Wort zu Methoden und Ressourcen

Wir haben viel über Ressourcen als physische Ressourcen im Dateisystem eines Servers gesprochen. Sehr oft sind Ressourcen wie PDF-Dateien, Videodateien, Bilddateien und Skriptdateien als physische Dateien auf dem Server vorhanden. Die URLs, die in vielen modernen Webanwendungen angezeigt werden, verweisen jedoch nicht wirklich auf Dateien. Technologien wie ASP.NET und Ruby on Rails werden die Anfrage nach einer Ressource abfangen und reagieren, wie sie es für richtig halten. Sie könnten eine Datei aus einer Datenbank lesen und den Inhalt der HTTP-Antwort zurückgeben, damit sie so aussieht, als wäre die Ressource tatsächlich auf dem Server selbst vorhanden.

Ein gutes Beispiel ist das POST-Beispiel, das wir zuvor verwendet haben, was zu einer Anfrage an /account/create führte. Wahrscheinlich gibt es keine echte Datei namens "create" in einem "account" -Verzeichnis. Stattdessen nimmt etwas auf dem Webserver diese Anforderung auf, liest und validiert die Benutzerinformationen und erstellt einen Datensatz in der Datenbank. Die Ressource /account/create ist virtuell und existiert nicht. Je mehr Sie sich jedoch eine virtuelle Ressource als echte Ressource vorstellen können, desto besser wird Ihre Anwendungsarchitektur und Ihr Design den Stärken von HTTP gerecht.


HTTP-Anforderungsheader

Bisher haben wir eine rohe HTTP-Anfrage gesehen und über die beiden populären HTTP-Methoden GET und POST gesprochen. Aber wie die Telnet-Ausgabe gezeigt hat, gibt es eine HTTP-Anfrage mehr als nur die HTTP-Methode. Eine vollständige HTTP-Anforderungsnachricht besteht aus den folgenden Teilen:

Die Nachricht befindet sich immer im ASCII-Text, und die Startzeile enthält immer die Methode, die URL und die HTTP-Version (am häufigsten 1.1, die es seit 1999 gibt). Der letzte Abschnitt, der Body-Abschnitt, kann Daten wie die Kontoanmeldungsparameter enthalten, die wir zuvor gesehen haben. Beim Hochladen einer Datei kann der Hauptteil sehr groß sein.

Der mittlere Abschnitt, der Abschnitt, in dem wir Host: odetocode.com gesehen haben, enthält einen oder mehrere HTTP-Header (denken Sie daran, in HTTP 1.1 host ist ein erforderlicher Header). Header enthalten nützliche Informationen, die einem Server bei der Verarbeitung einer Anfrage helfen können. Im letzten Artikel haben wir beispielsweise über Ressourcendarstellungen gesprochen und darüber, wie der Client und der Server über die beste Darstellung einer Ressource verhandeln können (Inhaltsverhandlung). Wenn der Client beispielsweise eine Ressource in Französisch sehen möchte, kann er einen Header-Eintrag (den Accept-Language-Header) enthalten, der französischen Inhalt anfordert.

Es gibt zahlreiche Header, die durch die HTTP-Spezifikation definiert sind. Einige der Header sind allgemeine Header, die in einer Anfrage oder einer Antwortnachricht erscheinen können. Ein Beispiel ist Date header. Der Client oder Server kann eine Date header enthalten, die angibt, wann die Nachricht erstellt wurde.

Alles außer dem Host-Header ist optional, aber wenn ein Header erscheint, muss er den Standards folgen. Zum Beispiel sagt die HTTP-Spezifikation, dass der Wert des Datumsheaders im RFC822-Format für Daten sein muss.

Einige der populäreren Anforderungsheader erscheinen in der folgenden Tabelle.

Header Beschreibung
Referer Wenn der Benutzer auf einen Link klickt, kann der Client die URL der verweisenden Seite in diesem Header senden.
User-Agent Informationen über den Benutzeragenten (die Software), der die Anfrage stellt. Viele Anwendungen verwenden die Informationen in dieser Header, wenn sie vorhanden sind, um herauszufinden, welcher Browser die Anfrage stellt (Internet Explorer 6 versus Internet Explorer 9 versus Chrome usw.).
Accept Beschreibt die Medientypen, die der Benutzeragent akzeptieren möchte. Dieser Header wird für die Inhaltsverhandlung verwendet.
Accept-Language Beschreibt die vom Benutzeragenten bevorzugten Sprachen.
Cookie Enthält Cookie-Informationen, die wir in einem späteren Kapitel betrachten werden. Cookie-Informationen helfen einem Server im Allgemeinen, einen Benutzer zu verfolgen oder zu identifizieren.
If-Modified-Since Wird ein Datum enthalten, an dem der Benutzeragent die Ressource zuletzt abgerufen (und zwischengespeichert) hat. Der Server muss nur die gesamte Ressource zurücksenden, wenn sie seither geändert wurde.

Eine vollständige HTTP-Anfrage könnte wie folgt aussehen.

Wie Sie sehen, enthalten einige Header mehrere Werte, wie den Accept-Header. Der Accept-Header listet die MIME-Typen auf, die er gerne sieht, einschließlich HTML, XHTML, XML und schließlich */* (d.h. ich mag HTML am besten, aber Sie können mir alles schicken (*/*) und ich versuche es herauszufinden).

Beachten Sie auch das Aussehen von "q" in einigen Headern. Der q-Wert ist immer eine Zahl von 0 bis 1 und repräsentiert den Qualitätswert oder "relativen Präferenzgrad" für einen bestimmten Wert. Der Standardwert ist 1.0 und höhere Zahlen weisen auf eine höhere Präferenz hin.


Die Antwort

Eine HTTP-Antwort hat eine ähnliche Struktur wie eine HTTP-Anfrage. Die Abschnitte einer Antwort sind:

Die vollständige HTTP-Antwort auf die letzte vollständige Anforderung, die wir aufgelistet haben, könnte so aussehen (wobei der größte Teil des HTML aus Platzgründen weggelassen wurde).

Die erste Zeile einer Anfrage beginnt mit der HTTP-Version und dann dem wichtigen Statuscode und Grund.


Antwortstatuscodes

Der Statuscode ist eine durch die HTTP-Spezifikation definierte Nummer, und alle Zahlen fallen in eine von fünf Kategorien.

Reihe Kategorie
100-199 Informativ
200-299 Erfolgreich
300-399 Umleitung
400-499 Clientfehler
500-599 Serverfehler

Obwohl wir nicht alle möglichen HTTP-Statuscodes aufführen, werden in der folgenden Tabelle die gebräuchlichsten Codes aufgeführt.

Code Grund Beschreibung
200 OK Der Statuscode, den jeder sehen möchte. Ein 200 Code in der Antwort bedeutet, dass alles funktioniert hat!
301 Moved Permanently Die Ressource wurde an die URL verschoben, die im Header Location angegeben wurde, und der Client muss diese URL nie erneut überprüfen.

Wir haben ein Beispiel dafür früher gesehen, als wir Telnet verwendet haben und der Server uns von www.odetocode.com zu odetocode.com umgeleitet hat, um Suchmaschinen eine kanonische URL zu geben.
302 Moved Temporarily Die Ressource wurde in die URL verschoben, die in der Location Header angegeben ist. In Zukunft kann der Client die URL noch anfordern, da es sich um einen temporären Umzug handelt.

Diese Art von Antwortcode wird normalerweise nach einer POST-Operation verwendet, um einen Client auf eine Ressource zu verschieben, die er mit GET abrufen kann (das POST/Redirect/GET-Muster, über das wir bereits gesprochen haben).
304 Not Modified Das ist der Server, der dem Client mitteilt, dass sich die Ressource seit dem letzten Abruf der Ressource durch den Client nicht geändert hat, sodass er nur eine lokal zwischengespeicherte Kopie verwenden kann.
400 Bad Request Der Server konnte die Anforderung nicht verstehen. Die Anfrage verwendete wahrscheinlich eine falsche Syntax.
403 Forbidden Der Server hat den Zugriff auf die Ressource verweigert.
404 Not Found Ein beliebter Code, der bedeutet, dass die Ressource nicht gefunden wurde.
500 Internal Server Error Der Server hat bei der Verarbeitung der Anforderung einen Fehler festgestellt. Häufig passiert das aufgrund von Programmierfehlern in einer Webanwendung.
503 Service Unavailable Der Server wird die Anfrage derzeit nicht bearbeiten. Dieser Statuscode kann angezeigt werden, wenn ein Server Anforderungen einschränkt, da er stark ausgelastet ist.

Antwortstatuscodes sind ein unglaublich wichtiger Teil der HTTP-Nachricht, da sie dem Client mitteilen, was passiert ist (oder im Fall von Weiterleitungen, wohin als nächstes zu gehen).


HTTP-Statuscodes im Vergleich zu Ihrer Anwendung

Denken Sie daran, dass der HTTP-Statuscode ein Code ist, der angibt, was auf der HTTP-Ebene geschieht. Es spiegelt nicht unbedingt wider, was in Ihrer Anwendung passiert ist. Stellen Sie sich beispielsweise vor, dass ein Benutzer ein Anmeldeformular an den Server sendet, das Feld Nachname jedoch nicht ausgefüllt hat. Wenn für Ihre Anwendung ein Nachname erforderlich ist, kann kein Konto für den Benutzer erstellt werden. Das bedeutet nicht, dass Sie einen HTTP-Fehlercode zurückgeben müssen, der auf einen Fehler hinweist. Wahrscheinlich möchten Sie, dass genau das Gegenteil passiert - Sie möchten einige Inhalte mit einem 200 (OK) Statuscode an den Client zurückgeben. Der Inhalt teilt dem Benutzer mit, dass ein Nachname nicht angegeben wurde. Aus Anwendungsansicht war die Anfrage ein Fehler, aber aus einer HTTP-Perspektive wurde die Anfrage erfolgreich verarbeitet. Das ist in Webanwendungen normal.


Antwortheader

Eine Antwort enthält Header-Informationen, die Client-Metadaten zur Verarbeitung der Antwort bereitstellen. Zum Beispiel wird der Inhaltstyp als MIME-Typ angegeben, wie wir im letzten Artikel besprochen haben. In der folgenden Antwort können wir sehen, dass der Inhaltstyp HTML ist und der Zeichensatz, der zum Codieren des Typs verwendet wird, UTF-8 ist. Die Header können auch Informationen über den Server enthalten, wie den Namen der Software und die Version.

Die Antwortheader, die angezeigt werden, hängen oft von der Art der Antwort ab. Beispielsweise muss eine Umleitungsantwort einen Location-Header enthalten, der dem Client mitteilt, wohin er als nächstes gehen soll.

Es gibt eine Reihe von Headers, die Caching und Leistungsoptimierungen gewidmet sind. ETag, Expires und Last-Modified liefern alle Informationen über die Cache-Fähigkeit einer Antwort. Ein ETag ist ein Bezeichner, der sich ändert, wenn sich die zugrunde liegende Ressource ändert. Daher ist der Vergleich von ETags eine effiziente Methode, um festzustellen, ob etwas aktualisiert werden muss. Ein Expires-Header teilt einem Client mit, wie lange eine bestimmte Ressource zwischengespeichert werden soll. Wir werden später zurückkehren und Caching genauer betrachten.


Wo sind wir?

In diesem Kapitel haben wir gelernt, dass HTTP-Nachrichten immer paarweise kommen. Zuerst gibt es die Anfrage, und dann gibt es die Antwort. Die Informationen in diesen Nachrichten sind alle in lesbarem Text und es gibt viele Tools, mit denen Sie HTTP-Anforderungen überprüfen können, die auf Ihrem Computer erstellt wurden. Fiddler ist ein solches Tool, wenn Sie Windows (http://fiddler2.com) ausführen. Es ist einfach zu verwenden, und Sie können die unbearbeiteten HTTP-Anfragen sehen, einschließlich aller Überschriften.

Bei den Nachrichten geht es darum sicherzustellen, dass beide Parteien in einer Transaktion verstehen, was sie erhalten. Die erste Zeile einer HTTP-Nachricht ist immer explizit über ihre Absicht. In einer Anforderungsnachricht werden zuerst die URL- und die HTTP-Methode angezeigt, um zu ermitteln, was mit einer bestimmten Ressource geschehen soll. In einer Antwort zeigt der Statuscode an, wie die Anfrage verarbeitet wurde. Wir haben auch Header, die sich in beide Richtungen bewegen, die noch mehr Informationen über die Anfrage und die Antwort liefern. Im nächsten Kapitel erfahren Sie, wie diese Nachrichten im Netzwerk übertragen werden.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.