Share
HTTP steht für Hypertext Transfer Protocol. Es ist ein zustandsloses Protokoll auf Anwendungsebene für die Kommunikation zwischen verteilten Systemen und bildet die Grundlage des modernen Webs. Als Webentwickler müssen wir alle dieses Protokoll genau verstehen.
Lassen Sie uns dieses leistungsstarke Protokoll durch die Linse eines Webentwicklers überprüfen. Wir werden das Thema in zwei Teilen behandeln. In diesem ersten Beitrag werden die Grundlagen behandelt und die verschiedenen Anforderungs- und Antwortheader beschrieben. Im Folgeartikel werden wir bestimmte Teile von HTTP - Caching, Verbindungsverarbeitung und Authentifizierung - überprüfen.
Obwohl ich einige Details zu Kopfzeilen erwähne, empfiehlt es sich, den RFC (RFC 2616) für eine ausführliche Abdeckung zu konsultieren. Ich werde im gesamten Artikel auf bestimmte Teile des RFC verweisen.
Wenn Sie Probleme mit einem HTTP-Fehler in WordPress haben, der behoben werden muss, können Sie einen Express-HTTP-Fehlerbehebung bei Envato Studio bestellen und den Fehler an einem Tag für nur 50 € beheben lassen.
HTTP ermöglicht die Kommunikation zwischen verschiedenen Hosts und Clients und unterstützt eine Mischung von Netzwerkkonfigurationen.
Um dies zu ermöglichen, nimmt es nur sehr wenig von einem bestimmten System an und behält den Zustand zwischen verschiedenen Nachrichtenaustausch nicht bei.
Dies macht HTTP a staatenlos Protokoll. Die Kommunikation erfolgt normalerweise über TCP / IP, es kann jedoch jeder zuverlässige Transport verwendet werden. Der Standardport für TCP / IP ist 80, Es können aber auch andere Ports verwendet werden.
Benutzerdefinierte Header können auch vom Client erstellt und gesendet werden.
Die Kommunikation zwischen einem Host und einem Client erfolgt über a Anforderungs- / Antwortpaar. Der Client initiiert eine HTTP-Anforderungsnachricht, die im Gegenzug über eine HTTP-Antwortnachricht bedient wird. Wir werden dieses grundlegende Nachrichtenpaar im nächsten Abschnitt betrachten.
Die aktuelle Version des Protokolls ist HTTP / 1.1, Dies fügt der vorherigen Version 1.0 einige zusätzliche Funktionen hinzu. Die wichtigste davon beinhaltet meiner Meinung nach dauerhafte Verbindungen, Chunked Transfer-Codierung und feinkörnige Cache-Header. Wir werden diese Features in diesem Artikel kurz ansprechen; Der zweite Teil wird ausführlich behandelt.
Im Zentrum der Webkommunikation steht die Anforderungsnachricht, die über URL-Adressen (Uniform Resource Locators) gesendet wird. Ich bin sicher, dass Sie bereits mit URLs vertraut sind, aber der Vollständigkeit halber werde ich sie hier angeben. URLs haben eine einfache Struktur, die aus folgenden Komponenten besteht:
Das Protokoll ist typisch http, aber es kann auch sein https für eine sichere Kommunikation. Der Standardport ist 80, man kann jedoch explizit gesetzt werden, wie im obigen Bild dargestellt. Der Ressourcenpfad ist der lokaler Pfad zu der Ressource auf dem Server.
Es gibt auch Web-Debugging-Proxys wie Geiger unter Windows und Charles Proxy für OSX.
URLs geben die Identität des jeweiligen Hosts an, mit dem wir kommunizieren möchten. Die auf dem Host durchzuführende Aktion wird jedoch über HTTP-Verben angegeben. Natürlich gibt es mehrere Aktionen, die ein Client vom Host ausführen lassen möchte. HTTP wurde auf einigen wenigen Systemen formalisiert, die das Wesentliche erfassen, das für alle Arten von Anwendungen universell anwendbar ist.
Diese Anforderungsverben sind:
Die oben genannten vier Verben sind die beliebtesten, und die meisten Werkzeuge und Frameworks setzen diese Anforderungsverben explizit offen. STELLEN und LÖSCHEN werden manchmal als spezialisierte Versionen des angesehen POST Verb, und sie können als verpackt werden POST Anfragen mit der Nutzlast, die die genaue Aktion enthält: erstellen, aktualisieren oder löschen.
Es gibt einige weniger verwendete Verben, die auch HTTP unterstützt:
Accentsconagua
Über Header-Feld. Dies kann zu Diagnosezwecken verwendet werden.Mit URLs und Verben kann der Client Anforderungen an den Server einleiten. Im Gegenzug antwortet der Server mit Statuscodes und Nachrichtennutzdaten. Der Statuscode ist wichtig und teilt dem Client mit, wie die Serverantwort zu interpretieren ist. Die HTTP-Spezifikation definiert bestimmte Nummernbereiche für bestimmte Arten von Antworten:
Alle HTTP / 1.1-Clients müssen das akzeptieren
Transfer-KodierungHeader.
Diese Klasse von Codes wurde in HTTP / 1.1 eingeführt und ist nur vorläufig. Der Server kann eine Erwarten Sie: 100 weiter Nachricht, die den Client anweist, den Rest der Anforderung weiter zu senden, oder ignorieren, wenn er sie bereits gesendet hat. HTTP / 1.0-Clients sollen diesen Header ignorieren.
Dies teilt dem Client mit, dass die Anforderung erfolgreich verarbeitet wurde. Der häufigste Code ist 200 OK. Für ein ERHALTEN Auf Anforderung sendet der Server die Ressource im Nachrichtentext. Es gibt andere, weniger häufig verwendete Codes:
404 gibt an, dass die Ressource ungültig ist und auf dem Server nicht vorhanden ist.
Dies erfordert, dass der Client zusätzliche Maßnahmen ergreift. Der häufigste Anwendungsfall besteht darin, zu einer anderen URL zu springen, um die Ressource abzurufen.
Ort Der Antwortheader enthält die temporäre URL.ETag (Entity-Tag) Informationen, die einen Hash des Inhalts darstellen. Der Server vergleicht dies mit seiner eigenen Berechnung ETag auf Änderungen prüfen.Diese Codes werden verwendet, wenn der Server der Meinung ist, dass der Client fehlerhaft ist, indem er entweder eine ungültige Ressource anfordert oder eine ungültige Anforderung stellt. Der beliebteste Code in dieser Klasse ist 404 Nicht gefunden, Ich denke, jeder wird sich mit identifizieren. 404 gibt an, dass die Ressource ungültig ist und auf dem Server nicht vorhanden ist. Die anderen Codes in dieser Klasse umfassen:
Genehmigung Header. Wenn der Client bereits die Genehmigung Header, dann waren die Anmeldeinformationen falsch.Diese Klasse von Codes wird verwendet, um einen Serverfehler während der Verarbeitung der Anforderung anzuzeigen. Der am häufigsten verwendete Fehlercode ist 500 Interner Serverfehler. Die anderen in dieser Klasse sind:
Bisher haben wir das gesehen URLs, Verben und Statuscodes bilden die grundlegenden Teile eines HTTP-Anfrage / Antwort-Paares.
Betrachten wir nun den Inhalt dieser Nachrichten. Die HTTP-Spezifikation gibt an, dass eine Anforderungs- oder Antwortnachricht die folgende generische Struktur aufweist:
message =* ( ) CRLF [ ] = Anforderungszeile | Statuszeile = Feldname ':' Feldwert
Es ist zwingend erforderlich, eine neue Zeile zwischen den Nachrichtenkopfzeilen und dem Nachrichtentext einzufügen. Die Nachricht kann eine oder mehrere Kopfzeilen enthalten, von denen die folgenden Kategorien enthalten sind:
Der Nachrichtentext kann die vollständigen Entitätsdaten enthalten, oder er kann stückweise sein, wenn die verschlüsselte Codierung (Transfer-Encoding: chunked) wird eingesetzt. Alle HTTP / 1.1-Clients müssen das akzeptieren Transfer-Kodierung Header.
Es gibt einige Header (allgemeine Header), die von Anforderungs- und Antwortnachrichten gemeinsam genutzt werden:
general-header = Cache-Control | Verbindung | Datum | Pragma | Trailer | Transfer-Kodierung | Upgrade | Über | Warnung
Wir haben bereits einige dieser Header speziell gesehen Über und Transfer-Kodierung. Wir werden abdecken Cache-Steuerung und Verbindung im zweiten Teil.
Der Statuscode ist wichtig und teilt dem Client mit, wie die Serverantwort zu interpretieren ist.
Über Der Header wird in einer TRACE-Nachricht verwendet und von allen intermittierenden Proxys und Gateways aktualisiertPragma wird als benutzerdefinierter Header betrachtet und kann verwendet werden, um implementierungsspezifische Header einzuschließen. Die am häufigsten verwendete Pragma-Direktive ist Pragma: kein Cache, was wirklich ist Cache-Control: kein Cache unter HTTP / 1.1. Dies wird in Teil 2 des Artikels behandelt.Datum Das Header-Feld wird zum Zeitstempel der Anforderungs- / Antwortnachricht verwendetAktualisierung wird verwendet, um Protokolle zu wechseln und einen reibungslosen Übergang zu einem neueren Protokoll zu ermöglichen.Transfer-Kodierung wird im Allgemeinen verwendet, um die Antwort in kleinere Teile zu zerlegen Transfer-Encoding: chunked Wert. Dies ist ein neuer Header in HTTP / 1.1 und ermöglicht das Streaming der Antwort an den Client anstelle einer großen Nutzlast.Anforderungs- und Antwortnachrichten können auch Entitätskopfzeilen enthalten, um Metainformationen über den Inhalt (bekannt als Nachrichtentext oder Entität) bereitzustellen. Diese Header enthalten:
entity-header = Erlaube | Inhalts-Kodierung | Inhaltssprache | Inhaltslänge | Inhaltsverzeichnis | Inhalt-MD5 | Inhaltsbereich | Inhaltstyp | Läuft ab Zuletzt bearbeitet
Alle der Inhalt- Präfix-Header enthalten Informationen zu Struktur, Codierung und Größe des Nachrichtentexts. Einige dieser Header müssen vorhanden sein, wenn die Entität Teil der Nachricht ist.
Das Läuft ab header gibt einen Zeitstempel an, wann die Entität abläuft. Interessanterweise a "läuft nie ab" Entität wird mit einem Zeitstempel von einem Jahr in die Zukunft gesendet. Das Zuletzt bearbeitet Header gibt den letzten Änderungszeitstempel für die Entität an.
Benutzerdefinierte Header können auch vom Client erstellt und gesendet werden. Sie werden vom HTTP-Protokoll als Entity-Header behandelt.
Dies ist wirklich ein Erweiterungsmechanismus, und einige Client-Server-Implementierungen können sich dazu entscheiden, speziell über diese Erweiterungsheader zu kommunizieren. HTTP unterstützt zwar benutzerdefinierte Header, es werden jedoch die Request- und Response-Header gesucht, die wir als Nächstes behandeln.
Die Anforderungsnachricht hat dieselbe generische Struktur wie oben, mit Ausnahme der Anforderungszeile, die wie folgt aussieht:
Request-Line = Methode SP URI SP HTTP-Version CRLF-Methode = "OPTIONS" | "HEAD" | "GET" | "POST" | "PUT" | "LÖSCHEN" | "SPUR"
SP ist das Leerzeichen zwischen den Token. HTTP-Version wird als angegeben "HTTP / 1.1" und dann folgt eine neue Zeile. Eine typische Anforderungsnachricht könnte daher wie folgt aussehen:
GET / articles / http-basics HTTP / 1.1 Host: www.articles.com Verbindung: keep-alive Cache-Kontrolle: no-cache Pragma: no-cache Akzeptieren: text / html, application / xhtml + xml, application / xml; q = 0,9, * / *; q = 0,8
Beachten Sie die Anforderungszeile, gefolgt von vielen Anforderungsheadern. Das Wirt Der Header ist für HTTP / 1.1-Clients obligatorisch. ERHALTEN Anforderungen haben keinen Nachrichtentext, aber POST Anfragen können die Postdaten im Hauptteil enthalten.
Die Anforderungsheader fungieren als Modifizierer der Anforderungsnachricht. Die vollständige Liste der bekannten Anforderungsheader ist nicht zu lang und wird nachstehend bereitgestellt. Unbekannte Header werden als Entity-Header-Felder behandelt.
request-header = Accept | Accept-Zeichensatz | Accept-Encoding | Accept-Language | Zulassung | Erwarten Sie | Von | Host | Wenn-Spiel | If-Modified-Since | Wenn-keine-Übereinstimmung | Wenn-Bereich | Wenn-unverändert? Seit | Max-Vorwärts | Proxy-Autorisierung | Bereich | Referer | TE | User-Agent
Das Akzeptieren Präfix-Header geben die auf dem Client akzeptablen Medientypen, Sprachen und Zeichensätze an. Von, Wirt, Referer und User-Agent Identifizieren Sie Details über den Client, der die Anforderung initiiert hat. Das Ob- Header mit Präfix werden verwendet, um eine Anforderung konditioneller zu machen, und der Server gibt die Ressource nur zurück, wenn die Bedingung erfüllt ist. Andernfalls wird a zurückgegeben 304 Nicht modifiziert. Die Bedingung kann auf einem Zeitstempel oder einem ETag (einem Hash der Entität) basieren..
Das Antwortformat ist mit Ausnahme der Statuszeile und der Header der Anforderungsnachricht ähnlich. Die Statuszeile hat folgende Struktur:
Statuszeile = HTTP-Version SP Statuscode SP Reason-Phrase CRLF
HTTP / 1.1 Eine typische Statuszeile für eine erfolgreiche Antwort könnte folgendermaßen aussehen:
HTTP / 1.1 200 OK
Die Antwortheader sind auch ziemlich begrenzt und der vollständige Satz ist unten angegeben:
Antwort-Header = Accept-Ranges | Alter | ETag | Standort | Proxy-Authentifizierung | Wiederholen nach | Server | Vary | WWW-Authentifizierung
Alter ist die Zeit in Sekunden, seit die Nachricht auf dem Server generiert wurde.ETag ist der MD5-Hash der Entität und wird zur Überprüfung auf Änderungen verwendet.Ort wird beim Senden einer Umleitung verwendet und enthält die neue URL.Server identifiziert den Server, der die Nachricht generiert.Bis zu diesem Punkt hat es viel Theorie gegeben, also werde ich Sie nicht für schläfrige Augen verantwortlich machen. In den nächsten Abschnitten werden wir praktischer werden und einen Überblick über die Tools, Frameworks und Bibliotheken geben.
Es gibt eine Reihe von Tools, um die HTTP-Kommunikation zu überwachen. Hier listen wir einige der beliebtesten Tools auf.
Zweifellos die Chrome / Webkit-Inspektor ist ein Favorit unter Webentwicklern:
Es gibt auch Web-Debugging-Proxys wie Geiger unter Windows und Charles Proxy für OSX. Mein Kollege Rey Bango schrieb einen hervorragenden Artikel zu diesem Thema.
Für die Befehlszeile haben wir Dienstprogramme wie curl, tcpdump und tshark zur Überwachung des HTTP-Verkehrs.
Nun, da wir uns die Anforderungs- / Antwortnachrichten angesehen haben, ist es an der Zeit, dass wir erfahren, wie Bibliotheken und Frameworks dies in Form einer API darstellen. Wir werden verwenden ExpressJS für Knoten, Ruby on Rails, und jQuery Ajax als unsere Beispiele.
Wenn Sie Webserver in NodeJS erstellen, ist die Wahrscheinlichkeit hoch, dass Sie ExpressJS in Betracht ziehen. ExpressJS wurde ursprünglich von einem Ruby-Web-Framework namens Sinatra inspiriert. Erwartungsgemäß wird auch die API gleichermaßen beeinflusst.
Da es sich bei uns um ein serverseitiges Framework handelt, gibt es beim Umgang mit HTTP-Nachrichten zwei Hauptaufgaben:
Das Verständnis von HTTP ist für eine saubere, einfache und RESTful-Schnittstelle zwischen zwei Endpunkten von entscheidender Bedeutung.
ExpressJS bietet dafür eine einfache API. Wir werden die Details der API nicht behandeln. Stattdessen bieten wir Links zu der ausführlichen Dokumentation zu den ExpressJS-Handbüchern. Die Methoden in der API sind in den meisten Fällen selbsterklärend. Eine Stichprobe der anforderungsbezogenen API ist unten aufgeführt:
Wirt Header-Feld.Auf dem Weg zum Client stellt ExpressJS die folgende Antwort-API bereit:
Die Anforderungs- und Antwortnachrichten sind größtenteils gleich, mit Ausnahme der ersten Zeile und der Nachrichtenköpfe.
In Rails stellen die Module ActionController und ActionDispatch die API für die Verarbeitung von Anforderungs- und Antwortnachrichten bereit.
ActionController Bietet eine API auf hoher Ebene, um die Anforderungs-URL zu lesen, die Ausgabe zu rendern und an einen anderen Endpunkt umzuleiten. Ein Endpunkt (auch als Route bezeichnet) wird als Aktionsmethode behandelt. Die meisten Kontextinformationen innerhalb einer Aktionsmethode werden über die bereitgestellt anfordern, Antwort und Params Objekte.
ActionDispatch ermöglicht einen feinkörnigen Zugriff auf die Anforderungs- / Antwortnachrichten über die ActionDispatch :: Request und ActionDispatch :: Response Klassen. Es stellt eine Reihe von Abfragemethoden bereit, um den Anfragetyp zu überprüfen (erhalten?(), Post?(), Kopf?(), lokal?()). Anforderungsheader können direkt über die aufgerufen werden request.headers () Methode.
Auf der Antwortseite gibt es festzulegende Methoden Kekse(), location = () und status = (). Wenn Sie abenteuerlustig sind, können Sie auch das einstellen body = () und das Rails-Wiedergabesystem umgehen.
Da es sich bei jQuery hauptsächlich um eine clientseitige Bibliothek handelt, bietet die Ajax-API das Gegenteil eines serverseitigen Frameworks. Mit anderen Worten, es erlaubt Ihnen lesen Antwortnachrichten und ändern Nachrichten anfordern. jQuery stellt eine einfache API über jQuery.ajax (Einstellungen) bereit:
Durch das Passieren eines die Einstellungen Objekt mit der beforeSend Rückruf können wir die Anforderungsheader ändern. Der Rückruf empfängt das Objekt jqXHR (jQuery XMLHttpRequest), das eine aufgerufene Methode verfügbar macht setRequestHeader () Überschriften setzen.
$ .ajax (url: 'http://www.articles.com/latest', Typ: 'GET', beforeSend: function (jqXHR) jqXHR.setRequestHeader ('Accepts-Language', 'en-US, en ');); jqXHR.getResponseHeader ().Statuscode Ruf zurück:$ .ajax (statusCode: 404: function () alert ("Seite nicht gefunden");); Das ist also eine kurze Zusammenfassung des HTTP-Protokolls.
Wir haben die URL-Struktur, Verben und Statuscodes überprüft: die drei Säulen der HTTP-Kommunikation.
Die Anforderungs- und Antwortnachrichten sind größtenteils gleich, mit Ausnahme der ersten Zeile und der Nachrichtenköpfe. Schließlich haben wir überprüft, wie Sie die Anforderungs- und Antwortheader in Web-Frameworks und Bibliotheken ändern können.
Das Verständnis von HTTP ist für eine saubere, einfache und RESTful-Schnittstelle zwischen zwei Endpunkten von entscheidender Bedeutung. In einem größeren Maßstab ist es auch hilfreich, wenn Sie Ihre Netzwerkinfrastruktur entwerfen und Ihren Endbenutzern eine großartige Erfahrung bieten.
In Teil zwei werden wir die Verbindungsverarbeitung, Authentifizierung und Zwischenspeicherung überprüfen! Bis dann.
