[Web-SIG] Reviewing WSGI open issues, again...
Phillip J. Eby
pje at telecommunity.com
Thu Sep 9 02:43:09 CEST 2004
* HTTP_AUTHENTICATION -- I haven't seen a concrete proposal for this yet,
and I don't personally consider it a high priority. If something is to go
in for this, somebody needs to put together a proposal, preferably in the
form of a patch to the PEP.
* Byte strings: so far the only discussion here has centered on character
sets required by HTTP RFCs. I'm going to loosen up the ASCII status/header
requirement slightly, to indicate that ISO-8859-1 is acceptable encoding,
per RFC 2616. Any other comments regarding byte string issues?
* 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?
* File-like objects -- I think anything we offer for file-like objects
should be optional. The big question is whether to offer a single,
introspection-based extension for all file-like things, or whether to use
separate extensions for different sorts of things, like 'wsgi.fd_wrapper'
for file descriptors and 'wsgi.nio_wrapper' for Java NIO objects,
etc. Does anybody have any arguments/use cases one way or the other?
* Configuration -- I'm going to mention that servers *should* provide an
easy way to configure name-value pairs to be supplied to an application's
'environ', and that one way to do that is simply to include OS environment
variables in 'environ'.
Am I missing anything else that's been discussed recently? (E.g. just
before I went into hiding from the hurricane...)
More information about the Web-SIG
mailing list