@pythonanfänger1: Da gibt es einige Probleme mit Namen und auch technische Probleme.
Die Namensschreibweise folgt nicht dem
Style Guide for Python Code. Und oft sind sie unpassend. `parseMessage()` macht deutlich mehr als nur die Nachricht vom Client zu parsen. Konkrete Datentypen sollten nicht bestandteil des Namens sein, weil man den konkreten Typ dann nicht mehr ändern kann, ohne überall den Namen anpassen zu müssen, oder Quelltext mit irreführenden Namen zu haben.
Der ``in``-Operator testet ob das erste Argument im zweiten *enthalten* ist; das ist aber nicht das was man in `parseMessage()` wissen möchte, denn eine Anfrage wie 'something GET /picture.jpg' wäre falsch, würde aber trotzdem von dem Test als richtig erkannt.
Es macht auch nicht so viel Sinn das *so* spezifisch zu machen. Denn das müsste man für die Textdatei auch noch mal machen. Hier würde sich eine allgemeine Funktion die GET-Anfragen beantwortet und die zur Verfügung stehenden Dateien als Argument erhält oder aus einer Konstante auf Modulebene, oder noch besser aus einem Unterverzeichnis wo die Dateien liegen. Also wie ein normaler Webserver. Im letzten Fall darf man nicht vergessen sicherzustellen, dass der Benutzer nicht über relative Pfadangaben in übergeordnete Verzeichnisse gelangen kann.
Man muss nicht jeden Wert an einen Namen binden, insbesondere wenn die nächste Aktion ein einfaches ``return`` mit diesem Namen ist. Und schon gar nicht muss man einen Wert an einen Namen binden, in der nächsten Zeile noch mal an einen *anderen* Namen, nur um den dann in der nächsten Zeile mit einem ``return`` zu verwenden.
Die Fehlerbehandlung in der Funktion ist nicht gut, denn der Aufrufer kann nicht zwischen einem regulären Dateiinhalt und einem Fehler unterscheiden.
`readAndReturnJPG()` ist überspezifisch. So etwas wie `AndReturn` gehört nicht in einen Namen. Wenn die Funktion `read_jpg()` heisst, ist normalerweise auch so klar was sie zurück gibt. Aber auch das `jpg` hat da nichts zu suchen, denn was das für ein Dateityp ist, sowie der fest kodierte Name *in* der Funktion sind schlecht entworfen. Einem Webserver ist an der Stelle völlig egal welche Daten in der Datei sind, die Bytes müssen einfach nur eingelesen werden. (Bei einem echten Webserver wird man das allerdings so nicht machen, denn es gibt ja auch richtig grosse Dateien, die man nicht komplett in den Speicher lesen möchte.)
In der Funktion ist auch der Fehler, denn entgegen dem Namen wird da nichts gelesen.
Dateien die man öffnet, sollte man auch wieder schliessen. Falls möglich bietet sich das öffnen zusammen mit der ``with``-Anweisung dafür an.
Importe gehören an den Anfang eines Moduls, damit man die Abhängigkeiten leichter sehen kann, und auch nicht das selbe Modul unnötig mehrfach importiert weil man übersehen hat, dass es irgendwo anders im Modul schon mal importiert wird.
Das gleiche gilt für die Definition von Konstanten.
Erstellen und Binden des Sockets gehört nicht auf Modulebene sondern zum Hauptprogramm.
Man sollte literale Zahlen nicht als Wahrheitswerte missbrauchen. ``while True:`` ist lesbarer als ``while 1:``.
Der `listen()`-Aufruf gehört nicht in die Schleife.
Das Lesen der Anfrage ist fehlerhaft. TCP ist ein Datenstrom und ein `recv()`-Aufruf kann einen beliebigen Teilausschnitt vom Anfang des Datenstroms liefern. Im Extremfall muss korrekter Socket-Code damit klar kommen, dass jedes Byte einzeln ankommt. Für einen einfachen Webserver muss man also mindestens solange `recv()` aufrufen bis man die erste Zeile der Anfrage empfangen hat, diese vom eventuell vorhandenen Rest abtrennen und dann verarbeiten.
Genau wie bei Dateien sollte man TCP-Verbindungen explizit schliessen. Damit die Gegenseite weiss, dass da keine Daten mehr kommen. Denn einen Size-Header sendest Du ja nicht, also kann der Client nur an der geschlossenen Verbindung erkennen, dass die Daten komplett sind. (Also eigentlich kann er daran nur erkennen, dass da keine weiteren Daten mehr folgen können.)
