At 06:21 PM 10/15/2007 +0200, Manlio Perillo wrote: >Phillip J. Eby ha scritto: > > At 05:52 PM 10/15/2007 +0200, Manlio Perillo wrote: > >> Hi. > >> > >> I'm implementing the start_response callable for Nginx mod_wsgi and I > >> have a few questions. > >> > >> 1) From the WSGI PEP it seems that an implementation is allowed to > >> *always* raise an exception when start_response is called with a not > >> null exc_info. > >> > >> Is this true? > > > > Yes - as long as it's the exc_info passed in, i.e.: > >It seems that WSGI *does not* requires the application to raise the >exc_info passed.
We're talking about the *server*, not the application: "if exc_info is provided, and the HTTP headers have already been sent, start_response MUST raise an error, and SHOULD raise the exc_info tuple." So, it's a "should" for the server, with the intent being that you should have some special reason for not doing so. This is later clarified in the PEP as meaning that exception-handling middleware may have reasons to raise an alternative error or not raise an error. However, there aren't any anticipated use cases for server gateways to do anything but raise the passed-in errors. > > > > try: > > raise exc_info[0], exc_info[1], exc_info[2] > > finally: > > del exc_info > > > > (this pattern of raising prevents the possibility of a reference cycle > > passing through the current stack location, keeping lots of objects > > around longer than necessary) > >Is this a concern for an implementation in C, too? No, because local variables in C don't get stored in a Python frame or traceback. The above is only relevant if start_response() is written in Python. >Well, I'm asking because in the current implementation I always raise an >exception, thus not allowing an application to "change its mind". Yeah, it's not required for an application to change its mind and send different non-error headers. I don't think that such an application would be WSGI compliant if it did. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
