On May 10, 12:07 pm, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > 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/
BTW, forgot to mention that one can always create a WSGI middleware component that does buffering and which only sends the complete response. If an error occurs while accumulating the response, then you can return a 500 status and error page of your own making. Graham -- http://mail.python.org/mailman/listinfo/python-list
