On Friday, September 19, 2003, at 04:26 PM, John Belmonte wrote:
> Simon Willison wrote:
>> I've recently started using Python for server side web development,
>> and I've been running in to some limitations in the CGI module.
> ...
>> I have previous experience with PHP, which has a number of extremely
>> convenient mechanisms for dealing with form input and cookies that I
>> sorely miss when working with Python. I have started work on porting
>> some of these capabilities, but it struck me that several of the
>> ideas represented would make valuable additions to the Python
>> standard library itself.
>
> Recently I was also thinking there is a lot of room for improvement.
> Although the Python libraries have objects that represent HTTP request
> and responses on the client side, there is no such thing for the
> server side to use from a CGI script.  (There is a little of this
> functionality mixed in with the HTTP server modules however.)
>
> I would like to see modules such as Quixote's http_request and
> http_response (which were taken from Zope) improved and incorporated
> into the standard library.  They do the essentials like manage
> headers, status, encoding, and cookies.  Something I found useful was
> that they can even parse headers such as Accept and give you a
> dictionary of MIME types that the client will accept.  The mod_python
> modules might also offer some ideas.

I think this would be an excellent idea -- providing some (*any*) basic
request and response implementation/interface would (hopefully) provide
some sort of basic vocabulary for generic Python web packages (i.e.,
packages that aren't tied specifically to one framework).  Right now
there isn't even a lowest common denominator, even though the
differences in the implementation of these interfaces isn't that great.
  If all a cgi (or web or whatever) module did was provide a request and
response object, that'd be a big improvement.

With certain criteria, I guess: it should be easy to create from a CGI
context, but not difficult from other contexts (i.e., given any
file-like input and output, and a dictionary of CGI-environment-like
variables).  It should also be general enough for most purposes, like
allowing streamed output, you mentioned accepting any POST body,
probably some other stuff.  But none of that is particular difficult to
do.

> Also, in any improvements that are made, I would like to see things
> kept general enough to support the REST architecture style [1].  In
> other words, don't assume that the client is always a web browser, or
> that the body of a POST is always a form, etc.  HTTP and CGI are for
> more than just serving web pages.