[Web-SIG] Why is response_headers a list instead of a dict?
Clark C. Evans
cce at clarkevans.com
Sun Dec 25 20:51:23 CET 2005
On Sun, Dec 25, 2005 at 02:13:00PM -0500, Phillip J. Eby wrote:
| In any case, the point is moot; this isn't a compatible change to the
| spec, so it would have to wait for a WSGI 2.0.
In paragraph #3 of the "start_response()" definition, it states that
type(response_headers) is ListType. I'm wondering if you'd be willing
to modify this to isinstance(response_headers, list)?
A similar assertion is not made about `environ` parameters, only that
it is a 'dictionary'. Could a server or middleware provide a special
environment handler object (as long as isinstance(environ, dict))?
The idea is that these two objects could be customized to provide
low-level RFC support and helper methods; but yet still be 'list of
tuples' and 'dictionary' as required by the WSGI specification.
(a) the specialized `environ` could provide attributes which
get common HTTP_HEADERs; or raise an error if they do not
exist -- this would prevent spelling mistakes.
(b) the specialized `headers` could override the list[selector]
to take a string argumnet, doing a lookup and replacement;
it could also do HTTP Header checking, etc.
Of course, the goal of these objects would be to present the _normal_
dict and list interfaces so that intermediate WSGI applications that
didn't know about the specialization would remain unaffected.
With Python 2.2's __new__ operator, this could be done transparently
at each level, where the intermediate object "adorns" the underlying
response_headers = ResponseHeaders(response_headers)
response_headers['My-Header'] = 'some-value'
The ResponseHeader class in this case would derive from 'list', and be a
valid WSGI list-of-tuples; for those that know it is a ResponseHeaders
however, they can use the goodness and type-checking provided. The
implementation of ResponseHeaders() constructor is simple; if the object
is already a ResponseHeaders, it returns self -- otherwise, it
constructs the wrapper as needed.
More information about the Web-SIG