Spaß mit Iteratoren :-/

[mitsuhiko]

http://wsgiarea.pocoo.org/trac/browser/ ... ication.py

wenn in der ObjectApplication ein Fehler geworfen wir bekomm ich folgendens zu sehen:

Code: Alles auswählen

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/flup-0.5-py2.4.egg/flup/server/fcgi_base.py", line 560, in run
    protocolStatus, appStatus = self.server.handler(self)
  File "/usr/lib/python2.4/site-packages/flup-0.5-py2.4.egg/flup/server/fcgi_base.py", line 1104, in handler
    write('') # in case body was empty
  File "/usr/lib/python2.4/site-packages/flup-0.5-py2.4.egg/flup/server/fcgi_base.py", line 1046, in write
    assert headers_set, 'write() before start_response()'
AssertionError: write() before start_response()

Quizfrage: "Warum?"

//EDIT: beispielsweise in den __iter__ bei BaseApplication ein RuntimeError rein. Funzt wunderbar mit BaseApplication, aber, wenn das über ObjectApplication aufgerufen wird kommt es zu diesem dummen fehler...

[modelnine]

So... Ich hab mir heute morgen mal ein bisschen den Quellcode von WSGI auf FastCGI angeguckt, und ich kann da eigentlich nicht erkennen warum er write('') aufrufen sollte bei der ObjectApplication.

Aber: ich bin noch nicht fertig.

--- Heiko.

[mitsuhiko]

Was ich bis jetzt raus hab, kommt ein write('') deswegen, weil die Anwendung __keinen__ output gesendet hat. Soweit sogut.
Aber was irritierend ist, ist, dass es nur bei der ObjectApplication mit diesem Fehler kommt. Weil die anderen senden ja auch kein start_response, wenn ein Fehler geworfen wird. Und das sollte alles nicht vom WSGI Wrapper abgehandelt werden, weil ja das colubrid debug system dazwischenfunkt und auf alle Fälle einen gültigen Output sendet. Egal in welchem Zustand die Anwendung war.