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/06 22:00] – [Was macht einen Text zu einem Hypertext?] 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 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 63: Zeile 68:
 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.: 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.:
  
-  * ''User-Agent'': Eine Bezeichnung für den Browser und die Version+  * ''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   * ''Referer'': Die URL der Webseite, die diesen Request ausgelöst hat
    
Zeile 70: Zeile 75:
  
 <code> <code>
-Server: www.qgelm.de+Host: www.qgelm.de
 </code> </code>
 zum Beispiel. zum Beispiel.
Zuletzt geändert: 2021/12/06 22:00
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