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

HTTP kurz: HTTP-Ressourcen

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

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

HTTP ist das Protokoll, das es uns ermöglicht, Mikrowellenherde von Amazon.com zu kaufen, mit einem alten Freund in einem Facebook-Chat zusammenzukommen und lustige Katzenvideos auf YouTube zu sehen.  HTTP ist das Protokoll hinter dem World Wide Web.  Es ermöglicht einem Webserver aus einem Datenzentrum in den Vereinigten Staaten, Informationen an ein Internetcafé in Australien zu senden, wo ein junger Student eine Webseite lesen kann, die die Ming-Dynastie in China beschreibt.

In diesem Buch betrachten wir HTTP aus der Sicht eines Softwareentwicklers.  Ein solides Verständnis von HTTP kann Ihnen helfen, bessere Webanwendungen und Webdienste zu schreiben.  Es kann Ihnen auch helfen, Anwendungen und Dienste zu debuggen, wenn etwas schief geht.  Wir werden alle Grundlagen einschließlich Ressourcen, Nachrichten, Verbindungen und Sicherheit in Bezug auf HTTP behandeln.

Wir beginnen mit Ressourcen.

Ressourcen

Der vielleicht bekannteste Teil des Webs ist die HTTP-Adresse.  Wenn ich ein Rezept für ein Gericht mit Brokkoli finden möchte, das fast nie ist, dann öffne ich vielleicht meinen Webbrowser und gebe http://food.com in die Adressleiste ein, um zur food.com-Website zu gehen und nach Rezepten zu suchen.  Mein Webbrowser versteht diese Syntax und weiß, dass er eine HTTP-Anfrage an einen Server namens food.com stellen muss.  Wir werden später darüber sprechen, was es bedeutet, "eine HTTP-Anfrage zu machen" und alle beteiligten Netzwerkdetails.  Vorerst wollen wir uns nur auf die Adresse konzentrieren: http://food.com.


Ressourcenlokalisierer

Die Adresse http://food.com nennen wir eine URL - einen Uniform Resource Locator.  Es stellt eine spezifische Ressource im Web dar.  In diesem Fall ist die Ressource die Startseite der Website von food.com.  Ressourcen sind Dinge, mit denen ich im Web interagieren möchte.  Bilder, Seiten, Dateien und Videos sind alle Ressourcen.

Es gibt Billionen, wenn nicht gar Billionen von Orten, an die man im Internet gehen kann - mit anderen Worten, es gibt Billionen von Ressourcen.  Jede Ressource hat eine URL, mit der ich sie finden kann.  http://news.google.com ist ein anderer Ort als http://news.yahoo.com.  Dies sind zwei verschiedene Namen, zwei verschiedene Firmen, zwei verschiedene Websites und daher zwei verschiedene URLs.  Natürlich gibt es auch verschiedene URLs innerhalb derselben Website.  http://food.com/recipe/broccoli-salad-10733/ ist die URL für eine Seite mit einem Brokkolisalatrezept, während http://food.com/recipe/grilled-cauliflower-19710/ noch am food.com ist, aber ist eine andere Ressource, die ein Blumenkohlrezept beschreibt.

Wir können die letzte URL in drei Teile unterteilen:

  1. http, der Teil vor dem ://, nennen wir das URL-Schema.  Das Schema beschreibt, wie auf eine bestimmte Ressource zugegriffen wird, und in diesem Fall teilt es dem Browser mit, das Hypertext-Übertragungsprotokoll zu verwenden.  Später betrachten wir auch ein anderes Schema, HTTPS, das das sichere HTTP-Protokoll ist.  Sie könnten auch auf andere Schemata stoßen, wie FTP für das Dateiübertragungsprotokoll und mailto für E-Mail-Adressen.

    Alles nach dem :// wird für ein bestimmtes Schema spezifisch sein.  Eine legale HTTP-URL darf also keine legale Mailto-URL sein - diese beiden sind nicht wirklich austauschbar (was sinnvoll ist, weil sie unterschiedliche Arten von Ressourcen beschreiben).

  2. food.com ist host.  Dieser Hostname teilt dem Browser den Namen des Computers mit, der die Ressource hostet.  Der Computer wird das Domain Name System (DNS) verwenden, um food.com in eine Netzwerkadresse zu übersetzen, und dann weiß es genau, wohin die Anfrage für die Ressource gesendet werden soll.  Sie können den Hostteil einer URL auch mithilfe einer IP-Adresse angeben.
  3. /recipe/grilled-cauliflower-19710/ ist der URL-Pfad.  Der food.com-Host sollte die spezifische Ressource erkennen, die von diesem Pfad angefordert wird, und entsprechend reagieren.

Manchmal verweist eine URL auf eine Datei auf dem Dateisystem oder der Festplatte des Hosts.  Zum Beispiel könnte die URL http://food.com/logo.jpg auf ein Bild zeigen, das wirklich auf dem food.com Server existiert.  Ressourcen können jedoch auch dynamisch sein.  Die URL http://food.com/recipes/brocolli  verweist wahrscheinlich nicht auf eine echte Datei auf dem food.com-Server.  Stattdessen wird auf dem Host von food.com eine Art Anwendung ausgeführt, die diese Anforderung übernimmt und eine Ressource mithilfe von Inhalten aus einer Datenbank erstellt.  Die Anwendung kann unter Verwendung von ASP.NET, PHP, Perl, Ruby on Rails oder einer anderen Webtechnologie erstellt werden, die auf eingehende Anforderungen zu reagieren weiß, indem HTML für die Anzeige eines Browsers erstellt wird.

Tatsächlich versuchen heutzutage viele Websites, in ihrer URL keinen echten Dateinamen zu haben.  Für den Anfang werden Dateinamen normalerweise mit einer bestimmten Technologie wie ASPX für Microsoft ASP.NET-Technologie verknüpft.  Viele URLs werden die Technologie überleben, die verwendet wird, um sie zu hosten und zu bedienen.  Zweitens möchten viele Seiten Schlüsselwörter in eine URL setzen (wie /recipe/broccoli/ in der URL für ein Brokkolirezept).  Diese Schlüsselwörter in der URL sind eine Form der Suchmaschinenoptimierung (SEO), die die Ressource in den Suchergebnissen höher einordnet.  Beschreibende Schlüsselwörter, nicht Dateinamen, sind heutzutage für URLs wichtig.

Einige Ressourcen führen auch dazu, dass der Browser zusätzliche Ressourcen herunterlädt.  Die Startseite von food.com enthält Bilder, JavaScript-Dateien, CSS und andere Ressourcen, die zusammen die "Homepage" von food.com darstellen.

Figure 1 foodcom home page

food.com-Startseite

Ports, Abfragezeichenfolgen und Fragmente

Nachdem wir nun über URL-Schemata, Hosts und Pfade informiert sind, sehen wir uns auch eine URL mit einer Portnummer an:

Die Zahl 80 steht für die Portnummer, die der Host zum Abhören von HTTP-Anfragen verwendet.  Die Standardportnummer für HTTP ist Port 80. Daher wird diese Portnummer normalerweise in einer URL nicht angegeben.  Sie müssen nur eine Portnummer angeben, wenn der Server einen anderen Port als Port 80 überwacht, was normalerweise nur in Test-, Debugging- oder Entwicklungsumgebungen geschieht.  Schauen wir uns eine andere URL an.

Alles danach?  (das Fragezeichen) wird als Abfrage bezeichnet.  Die Abfrage, auch Abfragezeichenfolge genannt, enthält Informationen zur Verwendung oder Interpretation der Zielwebsite.  Es gibt keinen formellen Standard dafür, wie die Abfragezeichenfolge aussehen sollte, da die Anwendung technisch gesehen die gefundenen Werte interpretieren kann. Sie sehen jedoch die meisten Abfragezeichenfolgen zum Übergeben von Name/Wert-Paaren im Formular name1=value1&name2=value2.

Zum Beispiel:

In diesem Beispiel gibt es zwei Name-Wert-Paare.  Das erste Paar hat den Namen "first" und den Wert "Scott".  Das zweite Paar hat den Namen "last" mit dem Wert "Allen".  In unserer früheren URL (http://www.bing.com/search?q=broccoli) wird der Bing-Suchmaschine der Name "q" zugeordnet, der mit dem Wert "broccoli" verknüpft ist.  Es stellt sich heraus, dass die Bing-Engine nach einem "q"-Wert sucht, der als Suchbegriff verwendet werden kann.  Wir können uns die URL als URL für die Ressource vorstellen, die die Bing-Suchergebnisse für Brokkoli darstellt.

Endlich noch eine URL:

Der Teil nach dem Zeichen # wird als Fragment bezeichnet.  Das Fragment unterscheidet sich von den anderen Stücken, die wir bisher betrachtet haben, da das Fragment im Gegensatz zum URL-Pfad und der Abfragezeichenfolge nicht vom Server verarbeitet wird.  Das Fragment wird nur auf dem Client verwendet und identifiziert einen bestimmten Abschnitt einer Ressource.  Insbesondere wird das Fragment normalerweise verwendet, um ein bestimmtes HTML-Element in einer Seite anhand der ID des Elements zu identifizieren.

Webbrowser richten die anfängliche Anzeige einer Webseite normalerweise so aus, dass der Anfang des Elements, das durch das Fragment identifiziert wird, oben auf dem Bildschirm angezeigt wird.  Als Beispiel hat die URL http://odetocode.com/Blogs/scott/archive/2011/11/29/programming-windows-8-the-sublime-to-the-strange.aspx#feedback den Fragmentwert " feedback".  Wenn Sie der URL folgen, sollte Ihr Webbrowser die Seite nach unten scrollen, um den Feedbackbereich eines bestimmten Blogposts in meinem Blog anzuzeigen.  Ihr Browser hat die gesamte Ressource (den Blogpost) abgerufen, Ihre Aufmerksamkeit jedoch auf einen bestimmten Bereich - den Feedbackbereich - gerichtet.  Sie können sich den HTML-Code für den Blogpost wie folgt vorstellen (wobei der gesamte Textinhalt weggelassen wird):

Der Client stellt sicher, dass das Element mit der ID "feedback" ganz oben steht.

Wenn wir alles zusammenfassen, was wir bisher gelernt haben, wissen wir, dass eine URL in folgende Teile unterteilt ist:


URL-Codierung

Alle Softwareentwickler, die mit dem Web arbeiten, sollten auf Zeichencodierungsprobleme mit URLs achten.  Die offiziellen Dokumente, die URLs beschreiben, bemühen sich sehr, URLs so nutzbar und interoperabel wie möglich zu machen.  Eine URL sollte so einfach per E-Mail zu kommunizieren sein, wie auf einem Autoaufkleber und auf einem 2001 Ford Windstar.  Aus diesem Grund definieren die Internetstandards unsichere Zeichen für URLs.  Zum Beispiel wird das Leerzeichen als unsicher angesehen, da Leerzeichen versehentlich erscheinen oder verschwinden können, wenn eine URL in gedruckter Form vorliegt (ist das ein Leerzeichen oder zwei Leerzeichen auf Ihrer Visitenkarte?).

Andere unsichere Zeichen enthalten das Nummernzeichen (#), da es zum Abgrenzen eines Fragments verwendet wird, und das Caret (^), da es nicht immer korrekt über alle Netzwerkgeräte übertragen wird.  RFC 3986 (das "Gesetz" für URLs) definiert die sicheren Zeichen für URLs als alphanumerische Zeichen in US-ASCII sowie einige Sonderzeichen wie den Doppelpunkt (:) und die Schrägstrichmarkierung (/).

Glücklicherweise können Sie weiterhin unsichere Zeichen in einer URL übertragen, aber alle unsicheren Zeichen müssen percent-encodiert sein (auch URL-codiert).  %20 ist die Codierung für ein Leerzeichen (wobei 20 der hexadezimale Wert für das US-ASCII-Leerzeichen ist).

Nehmen wir als Beispiel an, dass Sie die URL für eine Datei mit dem Namen "^ my resume.txt"  auf someserver.com erstellen möchten.  Die legale, codierte URL würde folgendermaßen aussehen:

Sowohl die Leerzeichen als auch die Leerzeichen wurden in Prozent codiert.  Die meisten Webanwendungs-Frameworks bieten eine API zur einfachen URL-Codierung.  Auf der Serverseite sollten Sie Ihre dynamisch erstellten URLs über eine Codierungs-API ausführen, falls eines der unsicheren Zeichen in der URL angezeigt wird.


Ressourcen und Medientypen

Bisher haben wir uns auf URLs konzentriert und alles andere vereinfacht.  Aber was bedeutet es, wenn wir eine URL in den Browser eingeben?  Normalerweise bedeutet das, dass wir eine Ressource abrufen oder anzeigen möchten. Es gibt eine enorme Menge an Material, das im Web angezeigt werden kann. Später werden wir sehen, wie HTTP es uns auch ermöglicht, Ressourcen zu erstellen, zu löschen und zu aktualisieren.  Im Moment werden wir uns auf das Retrieval konzentrieren.

Wir waren nicht sehr genau über die Arten von Ressourcen, die wir abrufen möchten.  Es gibt Tausende verschiedener Ressourcentypen auf den Web-Bildern, Hypertext-Dokumenten, XML-Dokumenten, Video, Audio, ausführbaren Anwendungen, Microsoft Word-Dokumenten und unzähligen weiteren.

Damit ein Host eine Ressource ordnungsgemäß bedienen kann und damit ein Client eine Ressource ordnungsgemäß anzeigen kann, müssen die beteiligten Parteien spezifisch und präzise über den Typ der Ressource sein.  Ist die Ressource ein Bild?  Ist die Ressource ein Film?  Wir möchten nicht, dass unsere Webbrowser versuchen, ein PNG-Bild als Text darzustellen, und wir möchten nicht, dass sie versuchen, Hypertext als Bild zu interpretieren.

Wenn ein Host auf eine HTTP-Anforderung antwortet, gibt er eine Ressource zurück und gibt auch den Inhaltstyp (auch Medientyp genannt) der Ressource an.  Wir werden im nächsten Kapitel die Details dazu sehen, wie der Inhaltstyp in einer HTTP-Nachricht angezeigt wird.

Zum Angeben von Inhaltstypen verwendet HTTP die MIME-Standards (MIME = Multipurpose Internet Mail Extensions).  Obwohl MIME ursprünglich für E-Mail-Kommunikation entwickelt wurde, verwendet HTTP für denselben Zweck MIME-Standards, die den Inhalt so kennzeichnen, dass der Client weiß, was der Inhalt enthält.

Wenn beispielsweise ein Client eine HTML-Webseite anfordert, kann der Host auf die HTTP-Anfrage mit etwas HTML antworten, das er als "text/html" bezeichnet.  Der "text" -Teil ist der primäre Medientyp, und der "html" ist der Medien-Subtyp.  Wenn der Host die Anfrage nach einem Bild beantwortet, kennzeichnet er die Ressource mit dem Inhaltstyp "image/jpeg" für JPG-Dateien, "image/gif" für GIF-Dateien oder "image/png" für PNG-Dateien.  Diese Inhaltstypen sind Standard-MIME-Typen und werden buchstäblich in der HTTP-Antwort angezeigt.


Eine kurze Anmerkung zu Dateierweiterungen

Sie könnten denken, dass ein Browser sich auf die Dateierweiterung verlassen würde, um den Inhaltstyp einer eingehenden Ressource zu bestimmen.  Wenn mein Browser beispielsweise "frog.jpg" anfordert, sollte er die Ressource als JPG-Datei behandeln, aber "frog.gif"  als GIF-Datei behandeln.  Bei den meisten Browsern ist die Dateierweiterung jedoch der letzte Ort, an dem der tatsächliche Inhaltstyp ermittelt wird.

Dateierweiterungen können irreführend sein, und nur weil wir eine JPG-Datei angefordert haben, heißt das nicht, dass der Server mit Daten antworten muss, die im JPG-Format kodiert sind.  Microsoft dokumentiert den Internet Explorer (IE), indem er zuerst das vom Host angegebene Inhaltstyp-Tag betrachtet.  Wenn der Host keinen Inhaltstyp bereitstellt, durchsucht IE dann die ersten 200 Byte der Antwort, die versucht, den Inhaltstyp zu erraten.  Wenn IE schließlich keinen Inhaltstyp findet und den Inhaltstyp nicht erraten kann, greift er auf die Dateierweiterung zurück, die in der Anforderung für die Ressource verwendet wird.  Das ist ein Grund, warum das Etikett mit dem Inhaltstyp wichtig ist, aber es ist bei weitem nicht der einzige Grund.


Inhaltstyp Verhandlung

Obwohl wir dazu neigen, HTTP als etwas zu sehen, das verwendet wird, um Webseiten zu bedienen, stellt sich heraus, dass die HTTP-Spezifikation ein flexibles, generisches Protokoll zum Verschieben von High-Fidelity-Informationen beschreibt.  Ein Teil der Aufgabe, Informationen zu verschieben, besteht darin, sicherzustellen, dass alle Beteiligten wissen, wie die Informationen zu interpretieren sind, und deshalb sind die Medientypeinstellungen wichtig.

Medientypen sind jedoch nicht nur für Hosts.  Clients können eine Rolle dabei spielen, welchen Medientyp ein Host zurückgibt, indem er an einer Inhaltstypaushandlung teilnimmt.

Eine Ressource, die durch eine einzelne URL identifiziert wird, kann mehrere Repräsentationen haben.  Nehmen wir zum Beispiel das Brokkoli-Rezept, das wir bereits erwähnt haben.  Das einzelne Rezept könnte Darstellungen in verschiedenen Sprachen (Englisch, Französisch und Deutsch) enthalten.  Das Rezept könnte sogar Darstellungen in verschiedenen Formaten (HTML, PDF und Klartext) haben.  Es ist die gleiche Ressource und das gleiche Rezept, aber unterschiedliche Darstellungen.

Die offensichtliche Frage ist: Welche Repräsentation sollte der Server auswählen?  Die Antwort liegt im Content-Verhandlungsmechanismus, der in der HTTP-Spezifikation beschrieben wird.  Wenn ein Client eine HTTP-Anforderung an eine URL sendet, kann der Client die Medientypen angeben, die er akzeptiert.  Die Medientypen dienen nicht nur zum Kennzeichnen ausgehender Ressourcen für den Host, sondern auch dazu, dass Clients den Medientyp angeben, den sie verwenden möchten.

Der Client gibt an, was er in der ausgehenden Anforderungsnachricht akzeptiert.  Auch in der nächsten Sitzung werden wir Details zu dieser Nachricht sehen, stellen Sie sich jedoch eine Anfrage auf http://food.com/ vor,  in der Sie eine Darstellung in deutscher Sprache akzeptieren.  Es liegt an dem Server, die Anfrage zu erfüllen.  Der Host könnte eine Textressource senden, die immer noch in Englisch ist, was einen deutschsprachigen Benutzer wahrscheinlich enttäuschen wird, aber das ist der Grund, warum wir es als Content-Negotiation und nicht als Content-Ultimatum bezeichnen.

Webbrowser sind hochentwickelte Softwareteile, die mit vielen verschiedenen Arten von Ressourcendarstellungen umgehen können.  Content-Negotiation ist etwas, was ein Benutzer wahrscheinlich nie interessieren würde, aber für Software-Entwickler (insbesondere Web-Service-Entwickler) ist Content-Negotiation Teil dessen, was HTTP großartig macht.  Ein in JavaScript geschriebener Code kann eine Anfrage an den Server stellen und nach einer JSON-Darstellung fragen.  Ein in C ++ geschriebener Code kann eine Anfrage an den Server stellen und nach einer XML-Darstellung fragen.  In beiden Fällen wird die Information, wenn der Host die Anforderung erfüllen kann, in einem idealen Format für das Parsen und den Verbrauch beim Client ankommen. 


Wo sind wir? 

An dieser Stelle sind wir so weit gegangen, wie wir gehen können, ohne uns mit den wesentlichen Details einer HTTP-Nachricht auseinanderzusetzen.  Wir haben Informationen zu URLs, URL-Codierung und Inhaltstypen erhalten.  Es ist Zeit zu sehen, wie diese Spezifikationen für Inhaltstypen aussehen, wenn sie über den Draht laufen.

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.