@Sebi.Schneider: Du solltest den Quelltext vielleicht mal etwas aufräumen. Zum Beispiel alles Unbenutze rauswerfen. Einiges von den Importen ist überflüssig. Das `address`-Argument der `ConnectionHandler.__init__()` wird nicht verwendet, und auch `ressource` und `handler` in `start()` nicht.
Die Methode `ConnectionHandler.method_others()` gibt es nicht. Dabei wäre es doch als ersten Schritt erstmal interessant einen funktionierenden, komplett transparenten Proxy zu schreiben und den zu testen, bevor man anfängt die Daten zu cachen und/oder zu verändern.
Das `thread`-Modul ist deprecated und sollte nicht mehr verwendet werden. Die Dokumentation verweist auf das `threading`-Modul.
In der `__init__` sollten alle Attribute definiert werden. `target` ist sehr undurchsichtig. Es wird am Ende der `__init__()` verwendet, aber die Methode die es definiert wird nur indirekt durch die `__init__()` aufgerufen. Das ist schlecht nachvollziehbar.
'GET' taucht in der Liste mit „anderen” HTTP-Kommandos auf, obwohl der Fall schon im ``if`` davor behandelt wird.
Statt ``while 1:`` ist ``while True:`` IMHO verständlicher.
`BUFLEN` wird nirgends definiert. Der Code ist so also gar nicht lauffähig.
Der Name `get_base_header()` ist auch nicht wirklich gut gewählt. An der Stelle sollte man vielleicht lieber eine Methode schreiben die eine Zeile liest, also beim nächsten Aufruf das auch die nächste Zeile zurück gibt. An der Stelle könnte man sich auch überlegen sich vom Socket-Objekt ein Dateiobjekt geben zu lassen. Da bekommt man die jeweils nächste Zeile mit `next()`.
Die Methode ist auch nicht robust. Wenn der Sender kein Zeilenende am Ende der Daten schickt, dann hängt die Methode.
``'%s' % obj`` ist ziemlich sinnfrei wenn `obj` vom Typ `str` ist.
Für Debug-Ausgaben bietet sich das `logging`-Modul an. Für Logausgaben sowieso.
Die Implementierung der GET-Methode hat das Problem, dass Du gar keine weiteren Header von der GET-Anfrage an den Webserver weiterleitest *bevor* Du die Antwort liest. Also eigentlich kannst Du `urlopen()` an der Stelle gar nicht einfach so verwenden, sondern müsstest das selbst implementieren.
Dateien die man öffnet sollte man auch wieder schliessen. Die Sprache garantiert nicht, dass die Objekte zeitnah zerstört werden wenn sie nicht mehr erreichbar sind und Dateideskriptoren sind ein verhältnismässig knappes Gut.
`readlines()`/`writelines()` ist hier auch eine unpassende Wahl denn es kann sich ja auch um Binärdaten handeln wie Bilder, wo es gar keine Zeilen gibt. Ausserdem ist alles auf einmal zu lesen problematisch. Denn spätestens wenn jemand ein DVD-Image lädt, bekommt man Probleme mit dem Arbeitsspeicher und er vielleicht sogar eine Zeitüberschreitung vom Browser weil der ja solange nichts vom Proxy hört bis der das Image komplett in den Speicher geladen hat.
Vom Pfad einfach ohne Erklärung die ersten sieben Zeichen abzuschneiden ist ziemlich „magisch”.
Für das Parsen von URLs gibt es in `urllib`/`urllib2` fertige Funktionen. Also zum Beispiel um Host und Port zu erfahren. Dann braucht man nicht immer dieses unschöne `find()`. Du müsstest auch mal probieren ob Dein Ansatz so mit Authentifikation klarkommt wenn jemand eine URL im Format '
http://user:password@domain/foo/bar' angibt.
Pfadkomponenten sollten mit `os.path.join()` zusammengesetzt werden. Der Pfad der dort zusammengesetzt und gegebenfalls erstellt wird, findet im weiteren dann aber gar keine Verwendung.
Vergleiche mit literalen `True` oder `False` sind schlechter Stil weil überflüssig. Da kommt doch bloss wieder ein Wahrheitswert bei heraus. Ob etwas Wahr ist kann man am Wert selber schon festmachen und wenn man das Gegenteil testen möchte, negiert man einfach mit ``not``.