[Web-SIG] Why is response_headers a list instead of a dict?
Phillip J. Eby
pje at telecommunity.com
Sun Dec 25 20:13:00 CET 2005
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
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.
More information about the Web-SIG