[Web-SIG] Reviewing WSGI open issues, again...

tony at lownds.com tony at lownds.com
Thu Sep 9 20:32:10 CEST 2004


> * Error handling -- I'm assuming the SIG consensus is +1 on the
> 'wsgi.fatal_errors' key, but haven't seen any feedback on my ideas for
> 'start_response', except that I seem to recall someone saying they didn't
> want the body passed to start_response.  Taking that part out, we end up
> with something like this:
>
> 'start_response()' doesn't actually transmit the status or headers until
> the first write() call occurs or the first string is yielded from the
> returned iterable.  'start_response' simply stores the status or headers
> for future use, and may therefore be called more than once.  However,
> calling 'start_response()' *after* a write(), or after the first string is
> yielded, is a fatal error.  Top-level servers/gateways should log detailed
> information about errors that occur after a partial result is
> transmitted.  They may also attempt to send error information to the
> client
> if the content type is text (e.g. text/html, text/xml, text/plain).
>
> Feedback, anyone?
>

I still like the idea of having an exception that servers will always
catch and send back to the user. If an application doesn't know whether a
server can display an error page, it will tend to include it's own
error-displaying logic (made simpler by the start_response() above). But,
if applications take care of displaying those exceptions, then exception
catching middleware won't really be useful for those applications.

As long as exceptions get logged, I think it is fine for there to be no
requirement about sending error data back to the client, after the
response is started.

Without some other way for applications to send errors, then the
additional requirements on start_response do make sense, even though it
complicates some pretty tricky logic.

How does wsgi.fatal_errors help servers? Wouldn't servers have to make up
specialized exceptions for inclusion in wsgi.fatal_errors, in order to
avoid interfering with catching other exceptions? Now write() and
start_response() need more logic, to throw only errors in
wsgi.fatal_errors. And servers can't rely on applications adhering to the
rules in the specs.

-Tony



More information about the Web-SIG mailing list