Qgelm

Zuletzt angesehen: › http_real_server

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung
Nächste Überarbeitung		Vorherige Überarbeitung
schulung:http [2021/12/05 23:34] – [Aber wie sieht ein wohldefinierter Request aus?] Thomasschulung:http [2022/01/31 15:09] (aktuell) – [Was macht es dann zu einem Protokoll?] Thomas
Zeile 1: Zeile 1:
 ====== HTTP ====== ====== HTTP ======
  
 +{{gallery>schulung:?http_req_resp_*.png&60x60&crop&lightbox}}
  
-Nachdem jetzt klar ist, wie grundsätzlich Inhalte zwischen zwei Rechnern //gesprochen// wird, wird es etwas konkreter: Der Server ist jetzt der Web-Server und der Client ist der Web-Browser. +Nachdem jetzt klar ist, wie grundsätzlich zwischen zwei Rechnern //gesprochen// wird, wird es etwas konkreter: Der Server ist jetzt der Web-Server und der Client ist der Web-Browser. 
 {{ :schulung:http_req_resp_00.png?400|}} {{ :schulung:http_req_resp_00.png?400|}}
 Dafür müssen sie sich auf eine gemeinsame Sprache verabreden, das ist das  Dafür müssen sie sich auf eine gemeinsame Sprache verabreden, das ist das 
Zeile 10: Zeile 11:
 Der Name scheint aus einer anderen Zeit zu stammen. Tatsächlich ist HTTP gar nicht so alt wie das Internet: Der Name scheint aus einer anderen Zeit zu stammen. Tatsächlich ist HTTP gar nicht so alt wie das Internet:
  
-  * RFC 1945 HTTP/1.0 (1996)+  * [[https://datatracker.ietf.org/doc/html/rfc1945|RFC 1945]] HTTP/1.0 (1996)
   * RFC 2616 HTTP/1.1 (1999)   * RFC 2616 HTTP/1.1 (1999)
   * RFC 7540 HTTP/2 (2015)   * RFC 7540 HTTP/2 (2015)
Zeile 20: Zeile 21:
 Es geht nicht nur um Text im landläufigen Sinn. Der Text enthält selbst noch Metadaten, die Formatierung und Textsatz ermöglichen und (ganz wichtig) es sind Elemente mit Interaktion möglich. Zuerst nur //Links//, die zu einem anderen Dokument verweisen, aber auch Formularelemente o.ä.. Es geht nicht nur um Text im landläufigen Sinn. Der Text enthält selbst noch Metadaten, die Formatierung und Textsatz ermöglichen und (ganz wichtig) es sind Elemente mit Interaktion möglich. Zuerst nur //Links//, die zu einem anderen Dokument verweisen, aber auch Formularelemente o.ä..
  
-Der Name steht für eine Gattung //moderner// Dokumente. Das prominenteste Format eines solchen Dokumententyps ist **HTML**:+Der Name steht für eine Gattung elektronischer Dokumente. Das prominenteste Format eines solchen Dokumententyps ist **HTML**:
  
 **H**yper**t**ext **M**arkup **L**anguage **H**yper**t**ext **M**arkup **L**anguage
Zeile 38: Zeile 39:
  
   - Der Browser (ein TCP-Client) stellt dem Server eine wohldefinierte Anfrage.    - Der Browser (ein TCP-Client) stellt dem Server eine wohldefinierte Anfrage. 
-  - Der Server antwortet auf demselben TCP-Kommuniationskanal exakt auf diese Anfrage mit einem Status-Code (OK oder irgend ein Fehler) und in einem und in einem Rutsch mit dem angefragten Inhalt.+  - Der Server antwortet auf demselben TCP-Kommuniationskanal exakt auf diese Anfrage mit einem Status-Code (OK oder irgend ein Fehler) und in einem Rutsch mit dem angefragten Inhalt.
   - Danach wird der Kommunikationskanal wieder abgebaut (so war das zumindest ganz zu Beginn, mittlerweile wartet der Server auf der einmal aufgebauten TCP-Verbindung, ob der Browser nicht direkt mehrere Requests loswerden möchte, das ist effizienter)   - Danach wird der Kommunikationskanal wieder abgebaut (so war das zumindest ganz zu Beginn, mittlerweile wartet der Server auf der einmal aufgebauten TCP-Verbindung, ob der Browser nicht direkt mehrere Requests loswerden möchte, das ist effizienter)
  
Zeile 44: Zeile 45:
  
 Ganz so einfach ist das heutzutage alles auch nicht mehr. Aber ein minimalistischer Webserver könnte genau so funktionieren. So ein Server ist beispielsweise ein sogenannter "statischer" Webserver, der Anfragen auf fest vorgegebene Inhalte oder an fixen Orten abgelegte Dokumente abbildet und mit diesen Inhalten antwortet. Ein solches Verhältnis zwischen Client und Server nennt man auch //zustandslos//, weil der //Response// völlig unabhängig von der Vorgeschichte der Kommunikation ausschließlich vom Inhalt des //Requests// abhängt: Gleiche Frage, gleiche Antwort!  Ganz so einfach ist das heutzutage alles auch nicht mehr. Aber ein minimalistischer Webserver könnte genau so funktionieren. So ein Server ist beispielsweise ein sogenannter "statischer" Webserver, der Anfragen auf fest vorgegebene Inhalte oder an fixen Orten abgelegte Dokumente abbildet und mit diesen Inhalten antwortet. Ein solches Verhältnis zwischen Client und Server nennt man auch //zustandslos//, weil der //Response// völlig unabhängig von der Vorgeschichte der Kommunikation ausschließlich vom Inhalt des //Requests// abhängt: Gleiche Frage, gleiche Antwort! 
 +
 +> **Erinnerung:** Das Ganze hängt wie folgt mit dem eben beschriebnene TCP/IP zusammen. //http// ist ein Protokoll, das sich auf die unteren Protokollschichten (TCP und IP darunter) stützt. Analysiert man jedes Byte der Daten, die zwischen Browser und Server gesendet werden, dann wird man die "ineinander geschachtelten" Protokollebenen wiedererkennen. Oder anders dargestellt: Jede Protokollebene verpackt die von den darüber liegenden Ebenen durchgereichten Daten in einen eigenen Datensatz und beim Empfang wird beim Durchlaufen der Protokollschichten wieder Schritt für Schritt "entpackt": 
 +{{:schulung:ip_nested.jpg?direct&400|}}
 +
  
 ===== Aber wie sieht ein wohldefinierter Request aus? ===== ===== Aber wie sieht ein wohldefinierter Request aus? =====
Zeile 53: Zeile 58:
 Aber man muss sich an eine strikte Konvention halten, damit der Text der Anfrage/des Requests auch von jeder Maschine einfach interpretiert werden kann und nicht kompliziert analysiert werden muss. Folgende Regeln muss der Browser beim Zusammenbau des Request einhalten: Aber man muss sich an eine strikte Konvention halten, damit der Text der Anfrage/des Requests auch von jeder Maschine einfach interpretiert werden kann und nicht kompliziert analysiert werden muss. Folgende Regeln muss der Browser beim Zusammenbau des Request einhalten:
  
-Der Text beginnt mit der ersten Zeile und dem ersten Zeichen, Leerzeichen sind Trenner zwischen den einzelnen Bestandteilen. +  * Der Text beginnt mit der ersten Zeile und dem ersten Zeichen, Leerzeichen sind Trenner zwischen den einzelnen Bestandteilen. 
-Das erste Wort ist ein Kommando, das beiden Seiten bekannt sein muss und im jeweils aktuellen RFC definiert wird: GET, POST, HEAD usw. +  * Das erste Wort ist ein Kommando, das beiden Seiten bekannt sein muss und im jeweils aktuellen RFC definiert wird: GET, POST, HEAD sind das bei Version 1.0. 
-Danach folgt als zweites Wort die sogenannte //Ressource//, also das Dokument, dass auf diesem Server angefragt wird. +  * Danach folgt als zweites Wort die sogenannte //Ressource//, also das Dokument, dass auf diesem Server angefragt wird.  
 +  * Zum Schluss wird die HTTP-Version genannt: ''HTTP/1.0'' z.B.
 Das ist der Mindestsatz an Informationen. Die Anfrage wird mit einer leeren Zeile beendet. Das ist der Mindestsatz an Informationen. Die Anfrage wird mit einer leeren Zeile beendet.
-Heutige Browser sind äußerst geschwätzig und übermitteln darüber hinaus (also vor der Leerzeile) noch jede Menge Zusatzinformation, die der Server bei der Auswahl und Zusammenstellung des Dokuments hinzuziehen kann, praktisch alles davon ist aber optional bei der einfachsten Request-Form, dem GET. Beispiele:+
 {{ :schulung:http_req_resp_01.png?400|}} {{ :schulung:http_req_resp_01.png?400|}}
  
-  * HTTP Version (z.B. "http/1.1") +Je nach HTTP Version können zwischen der ersten Zeile und der Leerzeile noch weitere sogenannte HTTP-Header-Zeilen eingebaut sein. Die sind optional, erleichtern dem Server aber eventuell etwas die Arbeit. Bei HTTP/1.0 wären das u.a.:
-  * Browser-Typ (z.B." +
-  * Landessprache +
-  * unterstützte Dokumenttypen (außer HTML) +
-  * Cookie-Werte von vorherigen Besuchen dieses Servers+
  
-Ab HTTP 1.1 folgt nach der Zeile mit dem Kommando (also z.B. "GET /index.html") immer eine Zeile, aus der der Name des Servers, so wie der Browser ihn nennt, ablesbar ist:+  * ''User-Agent'': Eine Bezeichnung für den Browser und die Version (z.B. ''User-Agent: Mozilla/5.0'') 
 +  * ''Referer'': Die URL der Webseite, die diesen Request ausgelöst hat 
 +  
 + 
 +Ab HTTP 1.1 folgt nach der Zeile mit dem Kommando (also z.B. "GET /index.html HTTP/1.1") immer eine Zeile, aus der der Name des Servers, so wie der Browser ihn nennt, ablesbar ist:
  
 <code> <code>
-Server: www.qgelm.de+Host: www.qgelm.de
 </code> </code>
 zum Beispiel. zum Beispiel.
-Das hat erst mal nichts mit der IP-Adresse des Servers zu tun. Aber es ist durchaus üblich, dass ein Server mit einer IP-Adresse verschieden Namen haben kann und verschieden reagiert. Zum Zusammenhang des //Namens// mit der //IP-Adresse// gibt es hier einen kleinen [[schulung:DNS|Exkurs]].+Es ist durchaus üblich, dass ein Server mit einer IP-Adresse verschiedene Namen haben kann und je nach Namen verschieden reagiert. Zum Zusammenhang des //Namens// mit der //IP-Adresse// gibt es hier einen kleinen [[schulung:DNS|Exkurs]].
  
 Der Server schaut dann, wie er den Inhalt der angeforderten Ressource bekommt und packt das wie folgt in seinen //Response//: Der Server schaut dann, wie er den Inhalt der angeforderten Ressource bekommt und packt das wie folgt in seinen //Response//:
 {{ :schulung:http_req_resp_02.png?400|}} {{ :schulung:http_req_resp_02.png?400|}}
   * Er nennt das verwendete Protokoll mit Version also z.B. ''http/1.1'').   * Er nennt das verwendete Protokoll mit Version also z.B. ''http/1.1'').
-  * Wenn alle glatt lief folgt dann der Statuscode mit Zahl und Kurzbeschreibung ''200 OK''. +  * Wenn alles glatt lief folgt dann der Statuscode mit Zahl und Kurzbeschreibung ''200 OK''. 
   * Bis hier war alles in einer Zeile. Die nächsten Zeilen können dann weitere sogenannte //HTTP-Header// enthalten, sind aber optional.   * Bis hier war alles in einer Zeile. Die nächsten Zeilen können dann weitere sogenannte //HTTP-Header// enthalten, sind aber optional.
-  * Die eigentlich übermittelte Ressource folgt dann nach einer Leerzeile und wird einfach angehängt.+  * Die eigentlich übermittelte Ressource folgt dann nach einer Leerzeile und wird einfach Byte für Byte angehängt. 
 + 
 +Der RFC für Version 1.0 definiert den übermittelten Statuscode übrigens so: 
 + 
 +<code> 
 +Status-Code    = "200"   ; OK 
 +               | "201"   ; Created 
 +               | "202"   ; Accepted 
 +               | "204"   ; No Content 
 +               | "301"   ; Moved Permanently 
 +               | "302"   ; Moved Temporarily 
 +               | "304"   ; Not Modified 
 +               | "400"   ; Bad Request 
 +               | "401"   ; Unauthorized 
 +               | "403"   ; Forbidden 
 +               | "404"   ; Not Found 
 +               | "500"   ; Internal Server Error 
 +               | "501"   ; Not Implemented 
 +               | "502"   ; Bad Gateway 
 +               | "503"   ; Service Unavailable 
 +</code> 
 + 
 +Wenn man nicht (unbemerkt) meistens den Status ''200 OK'' auslöst, dann ist wohl der am meisten beachtete Status ''404 Not Found''. Das passiert immer, wenn die angeforderte Ressource für den Server nicht auffindbar ist, also z.B. der Link auf einer Webseite veraltet ist oder ein Vertipper passiert ist.
  
 Kommen wir nach der Vorrede zu einem einfachen [[schulung:statischer_http_server|Beispiel eines statischen HTTP-Servers]]. Kommen wir nach der Vorrede zu einem einfachen [[schulung:statischer_http_server|Beispiel eines statischen HTTP-Servers]].
Zuletzt geändert: 2021/12/05 23:34
CC Attribution-Noncommercial-Share Alike 4.0 International Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International