[Web-SIG] Request/Response features

David Fraser davidf at sjsoft.com
Thu Oct 23 06:08:36 EDT 2003

Simon Willison wrote:

> Ian Bicking wrote:
>> I've very interested into getting some sort of sane request/response 
>> object into the Python standard library, to form the basis of an 
>> informal standard on how those objects should look (even if wrappers 
>> or adaptation are required for most frameworks).  Technically I 
>> suppose cgi.FieldStorage is a request object, but it's not a very 
>> good one, and it's very incomplete outside of CGI (e.g., output goes 
>> to sys.stdout, headers come from os.environ), and unusable in a 
>> threaded environment.
> I think that's an absolutely fantastic idea. Request / Response 
> objects are the one thing that almost all Python web frameworks deal 
> with in some way, and a standardised interface for them in the 
> standard library could do a lot for improving cross-framework 
> compatibility.

Absolutely. I am busy constructing a toolkit (jtoolkit.sourceforge.net) 
for web applications, and have been looking at making it compatible with 
more than one web framework (so far mod_python and have started work on 
a standalone HTTP server). Having a standard interface to 
requests/responses would make life a lot easier.
In particular, having a standard HTTP server included with Python that 
supports these interfaces so applications can be tested without any 
other software.

>> A useful starting point might be to summarize the features that 
>> various request/response implementations already have.  Thoughts?  
>> Wild enthusiasm from anyone to take on the project?  If no one else 
>> is interested I could probably take this on.
> I have plenty of enthusiasm, but it's coupled with youthful ignorance 
> (I've been using Python for web development for just over a month). 
> That said, I'm happy to contribute serious time and effort to this.
> In a previous post I outlined the things that I liked about PHP's web 
> interface features, which while not exactly modelled on a 
> request/response object do cover the same ground. I think the most 
> valuable thing PHP's treatment of this brings to the table is the 
> concept of GET, POST and COOKIE dictionaries for looking up data sent 
> by the client (also the REQUEST dictionary which combines the three).

I think it's important that while we can take things from PHP, they need 
to be rethought to apply to a Python context... but the dictionaries 
sound great.

> One other thing I've been thinking about recently is that HTTP 
> requests and HTTP responses both consist of a set of headers and a 
> body, in a very similar way to MIME email messages which are already 
> well catered for by the standard library. I think any standard for 
> request/response objects should aim to closely match the way MIME 
> style messages are handled by other parts of the standard library (in 
> particular the email module).

Good point. The main difference is that in parsing email messages, you 
often have the whole message available, whereas in HTTP you need to be 
able to handle parts at a time (for example, when uploading files)


More information about the Web-SIG mailing list