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