[Web-SIG] some questions about start_response implementation

[Phillip J. Eby]

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.