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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
