[Web-SIG] Why is response_headers a list instead of a dict?

[Phillip J. Eby]

At 01:04 PM 12/25/2005 -0500, Clark C. Evans wrote:
>More control over the response is fine; but really, this should be
>in the domain of web-server software -- which will have much more eyes
>on it and has a greater chance of being correct and handling variants
>among browsers.  For example, Twisted or the Zope community have a much
>better chance of making WSGI work in pratice if they are given the
>freedom to re-arrange the Headers (splitting or joining as appropiriate)
>to match browsers which commonly visit their site.
>
>In this particular case, you've taken control from the writers of the
>web-server software (who have much greater chance of getting it right)
>and given it to framework/application writers -- which have a much
>larger chance of not reading the specifciations correctly or not having
>enough deployment experience to cover browser quirks.

WSGI puts this particular power in the application writer's hands, because 
then *they* can fix a problem.  If it's in the server author's hands, the 
application writer can be screwed, whether the server is open source or not.


>I think that server platforms should be able to
>implement these suggestions so that applications/frameworks don't have
>to be bothered with such details.

WSGI is not designed - and is definitely not intended! - to encourage 
writing new web frameworks.


>This seems to be the only use-case for the decision.  If it is that
>important; make it an exception.  A small bit of code for 'Set-Cookie',
>if it is even necessary (I contend that it isn't), is an acceptable
>price to pay for simpler WSGI applications.

No, I'm sorry, but it's not.  Read the PEP again, which explains why having 
a nicer API for the application side was never a goal - in fact, it was an 
explicit *anti*-goal.  Having it be ugly and primitive was both necessary 
and intentional.

Ironically, headers are the one use case where I felt we could make an 
exception to the "crude is better" principle, but was argued down by 
others.  I had originally proposed using an email.Message object to manage 
headers, since it had all the needed functionality (including the necessary 
ordering control), but others argued that it's easy enough for a framework 
to do that itself, and that in any case email.Message had too many 
distracting non-HTTP-header methods.


>Frankly -- this is programming for Edge Cases; it is a 1% issue and your
>average Framework/Application developer won't do it, or if they do do
>it, it will most likely be done incorrectly.  It's not like the servers
>we have to run WSGI apps are closed-source, non-responsive.  The Twisted
>and Zope team (among others) are very quick at making things work.

FYI, If I understand correctly, Jim Fulton has stated that Zope isn't going 
to *have* a server in the future, if they can avoid it.

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.

Note that in any case, every framework, application, or middleware is free 
to invent its own solution for managing headers - and most already had one 
before WSGI came into being.  As written, the WSGI spec allows those 
existing applications and frameworks to produce the same output that they 
used to.  Backward compatibility with field-deployed software was a key 
criterion for WSGI design decisions.  Moving from a non-WSGI interface to 
WSGI should not alter an application's output unnecessarily.

If you want a friendly API for WSGI header management, please see the 
wsgiref.headers.Headers class, which offers a dictionary-like interface to 
manipulate a WSGI header list.