On May 10, 8:26 am, Adam Atlas <[EMAIL PROTECTED]> wrote: > I'm trying to figure out if there's any defined behaviour in PEP 333 > for instances where an application returns an iterable as usual > without error, but that iterable's next() method eventually raises an > exception. Since any data theretofore returned by the iterable must be > assumed to have already been written to the client, thus making it > impossible to replace the response with a 500 error or somesuch, does > the gateway just absorb the exception and cut off the response there? > It seems like that's pretty much all it could do, but I'm wondering if > that's explicitly specified anywhere (I couldn't find anything about > that in the PEP).
Because the WSGI specification requires that a WSGI adapter for a web server always explicitly perform a flush after each string yielded from the iterator then simply cutting off the response at that point is all one can do as the first time a flush is done any response status and headers will also have to be written out. Now depending on the web server being used, all the client may see is the truncated page, or it might also see some form of error page appended to it by the underlying web server. For example, in Apache, if the WSGI adapter returns HTTP_INTERNAL_SERVER_ERROR back to the server, the server disregards whether anything has already been sent and tries to generate a 500 error page. Since the response status and headers have already been flushed though, the original status is received by the client, but the Apache error page content is still sent. Thus you might get output looking like: Hello World! <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>200 OK</title> </head><body> <h1>OK</h1> <p>The server encountered an internal error or misconfiguration and was unable to complete your request.</p> <p>Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error.</p> <p>More information about this error may be available in the server error log.</p> <hr> <address>Apache/2.2.2 (Unix) mod_wsgi/1.0-TRUNK Python/2.3.5 Server at localhost Port 8002</address> </body></html> It is actually hard to know what to do here. There are ways one could stop the appending of the error page content, but is returning just the truncated page any better. At least the error page content in there highlights an issue even if status wasn't 500, but then not being 500, the page content could get cached. This is where one wanders whether the WSGI way of always flushing is a good idea. It may be better to always use buffering unless one specifically knows that one wants to do streaming of data where size could be large or take some time to produce. Anyway, for WSGI matters, you are probably better off bringing them up on the Python WEB-SIG list. http://www.python.org/community/sigs/current/web-sig/ Graham -- http://mail.python.org/mailman/listinfo/python-list
