World Wide Web - Grundlagen und Technologie

Musterlösung Aufgabe 3 (HTTP Protokoll)

Manuelle Simulation der Client- und Server-Seite von HTTP


Schritt 1 (Simulation eines HTTP-Clients)

Die syntaktischen Grundlagen des Protokolls sind im Standard selber geregelt. Generell fällt auf, dass das Protokoll wesentlich weniger fehlertolerant gegenüber Tippfehlern ist als andere Komponenten der Web-Architektur, wie z.B. HTML. der einfache Grund dafür liegt darin, dass HTTP an sich niemals von Hand eingegeben wird, sondern immer von Programmen generiert wird, die sich sehr einfach an rigorose Syntax-Vorschriften halten können.

Einige wichtige Beobachtungen im Zusammenhang mit HTTP sind:

  1. ohne die Port-Nummer (Standard ist 80) kommt man schon mal gar nicht an den Server heran...
  2. HTTP ist case sensitive, man muss also z.B. die Methoden im Request wirklich gross schreiben, sonst funktioniert es nicht.
  3. verwendet man HTTP/1.1, so muss man immer den Host Header angeben, da dieser in HTTP/1.1 verpflichtend vorgeschrieben wird.
  4. in HTTP/1.0 dagegen wird der Host Header zwar auch akzeptiert, er kann aber auch weggelassen werden (was Probleme verursacht mit name-based Virtual Hosts).

Beachtet man diese Regeln, kann man mit Hilfe des telnet Programmes (oder eines vergleichbaren Tools) auf sehr einfach Verbindungen zu HTTP-Servern herstellen und von diesen Informationen abfragen. Natürlich sind diese Informationen immer darauf beschränkt, was der jeweilige Server über HTTP herauszugeben bereit ist, und ein gut (im Sinne von "sicher") konfigurierter Server sollte keine kritischen Informationen herausgeben. Im folgenden eine Auflistung der in der Aufgabe angegebenen Server (die ausgegebenen Textteile sind jeweils hervorgehoben dargestellt):

Betrachtet man all diese Server-Responses, so sieht man, dass die Implementierungen von HTTP recht unterschiedlich sind, und offenbar auch noch sehr von der Konfiguration des Servers abhängen, drei der vier betrachteten Server sind ja Apache-Server.

Für einen kommerziell betriebenen Server wäre es weniger empfehlenswert, so mitteilsam hinsichtlich seiner Konfiguration zu sein wie es Apache meistens ist. Dies bietet nur Angriffspunkte für Hacker und hat keinerlei positive Auswirkungen auf die Protokollverwendung. Am wenigsten empfehlenswert in dieser Hinsicht ist natürlich die Art, wie der Server dret.net Auskunft über seine Konfiguration gibt, dies bietet einen exzellenten Angriffspunkt für Hacker. Wobei in diesem Fall noch gesagt werden muss, dass die Hacker auch erst einmal die beiden URIs wissen müssen, unter der man diese Informationen abfragen kann, und das ist eher unwahrscheinlich...


Schritt 2 (Simulation eines HTTP-Servers)

Die für die Erstellung der Tabelle notwendigen Daten wurden gewonnen, indem jeweils das nc Programm im Listen-Mode gestartet wurde auf einem für alle Benutzer zugänglichen Port, und dann mit einem Browser ein Request auf diesen Port geschickt wurde, indem der Rechnername und die Portnummer direkt im Adressfeld des Browsers eingegeben wurden. Die folgende Tabelle kommentiert nicht alle Header-Felder, sondern nur die wichtigsten. Interessant daran ist, dass selbst neue Browser wie Netscape 6.0 immer noch HTTP/1.0 verwenden.

Eine komplette Aufstellung aller Header-Felder findet sich im HTTP Standard oder, in besser lesbarer Form, im Buch zur Vorlesung.

HTTP Header Field erwartete Werte untersuchte Browser
PC/Windows Sun/Solaris
IE 5.5 / Win2000 Navigator 4.73 / WinNT40 Navigator 6.0 / Win95 Opera 3.60 / Win95 Amaya 2.4 / Win95 Amaya 3.1 / Win95 Navigator 3.04 Navigator 4.7 IE 5.0 Lynx 2.8.2 XMosaic 2.6
generierter Request: file file file file file file file file file file file
HTTP Version: HTTP/1.1 HTTP/1.0 HTTP/1.0 HTTP/1.0 HTTP/1.1 HTTP/1.1 HTTP/1.0 HTTP/1.0 HTTP/1.1 HTTP/1.0 HTTP/1.0
Accept sollte angeben, welche Medientypen vom Browser unterstützt werden, also sicher HTML und Bildcodierungen und vielleicht noch anderes (je nach Plug-Ins) gut, aber das */* am Ende ist suboptimal nicht schlecht, aber das */* am Ende ist suboptimal extrem schlecht (*/* und sonst nichts) nicht schlecht, aber das */* am Ende ist suboptimal extrem schlecht (*/* und sonst nichts) extrem schlecht (*/* und sonst nichts) nicht schlecht, aber das */* am Ende ist suboptimal nicht schlecht, aber das */* am Ende ist suboptimal nicht schlecht, aber das */* am Ende ist suboptimal perfekt, so sollte es bei allen sein! extrem schlecht (*/* und sonst nichts)
Accept-Language gibt die Sprachpräferenz des Benutzers an, falls der Browser so eine Möglichkeit vorsieht nur eine Sprache angegeben nur eine Sprache angegeben nicht schlecht, aber die q-Faktoren fehlen n/a n/a n/a n/a nur eine Sprache angegeben nur eine Sprache angegeben nur eine Sprache angegeben n/a
Connection Gibt "Connection Tokens" an, die für die Verbindung zwischen Cloient und Server gelten ok notwendig für persistent connections, weil HTTP/1.0 benutzt wird schlecht, HTTP/1.0 und somit keine persistent connections schlecht, HTTP/1.0 und somit keine persistent connections ok ok notwendig für persistent connections, weil HTTP/1.0 benutzt wird notwendig für persistent connections, weil HTTP/1.0 benutzt wird ok schlecht, HTTP/1.0 und somit keine persistent connections schlecht, HTTP/1.0 und somit keine persistent connections
User-Agent identifiziert den User Agent (also den Browser) gegenüber dem Server nennt sich aus Kompatibilitätsgründen "Mozilla/4.0" wie erwartet Mozilla/5.0 und Netscape/6.0, etwas verwirrend aber technisch ok nennt sich aus Kompatibilitätsgründen "Mozilla/4.0" wie erwartet wie erwartet wie erwartet wie erwartet nennt sich aus Kompatibilitätsgründen "Mozilla/4.0" wie erwartet wie erwartet

please send comments to www-vl@dret.net
last modification on Tuesday, 15-May-2001 05:34:38 EDT
valid CSS!valid HTML 4.01!