[Web-SIG] WSGI in standard library

[Clark C. Evans]

On Sun, Feb 19, 2006 at 04:33:49PM -0500, James Y Knight wrote:
| On Feb 19, 2006, at 4:22 PM, Ian Bicking wrote:
| >> - HTTP header parsing support, e.g. language codes, quality lists,  
| >> etc
| >
| > This would be very nice.  Clark has done some work in  
| > paste.httpheaders  for these; but I don't think any of us 
| > (Clark included) are really satisfied with how that module
| > is layed out.  Maybe it is because headers in general don't 
| > have that much in common with each other.  I'm not sure.
| >
| > But nevertheless, it's all very mechanical, and based on existing and
| > stable HTTP standards.  So I think it is an excellent candidate for  
| > the standard library.
| 
| I've done a bunch of work on this in twisted.web2, and it is pretty  
| much completely separable from the rest of the server (it doesn't  
| import any other twisted modules). I have parsers for almost all of  
| the standard HTTP headers. There is a standard header format that  
| many of the headers conform to.
| 
| http://svn.twistedmatrix.com/cvs/trunk/twisted/web2/http_headers.py? 
| view=auto

Something like this would be excellent in the standard library; the
sheer coverage of header parsing in your Twisted module is more complete
than what I did (for example, your date parsing and cookie handling
code).   We have a solid overlap in the general pattern which points
to the need of a standard python version of this stuff:

  For each header, there are two primary functions: a 'parse' function
  for reading headers, and a 'compose' function for generating them.

The rest of the module is more or less implementation details and
user-interface issues:

  - a class to store a collection of headers (found in your
    module and in wsgiref, but not in my implementation);

  - a mechanism to enumerate and list headers; both of our
    implementations do this;
    
  - specific objects for more complicated headers (ETag and
    Cookie) - your module provides this (mine doesn't);

  - providing for a mechanism to "extend" the header parsing
    mechanism so that header parse/compose pairs for custom
    or less common headers can be provided by "plug-in" 
    libraries (I use objects, you use a dict of tuples);

  - nice doc strings (your module could use a bit of help
    in this regard - plus cross reference to the particular
    RFC for the given header)

  - handling the fundmental distinction between headers that 
    have a single value, have multiple values as described
    by section 4.2 of RFC 2616, and headers which are not
    compliant with RFC 2616; and

  - integration /w WSGI; my module provides a uniform mechanism
    for accessing/setting headers in a WSGI ``environ`` dict or
    ``response_headers`` list.

In any case, it probably wouldn't be too much effort (a few days?)
to integrate the modules and document them for inclusion.

Kind Regards,

Clark