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

[Clark C. Evans]

I'm going to play the devil's advocate here; although I really love
WSGI -- I think this particular decision is a wart and will greatly
hinder adoption. 

On Sun, Dec 25, 2005 at 12:13:09AM -0500, Phillip J. Eby wrote:
| At 10:45 PM 12/24/2005 -0500, Clark C. Evans wrote:
| >Why is response_headers a list instead of a dict?
| 
| The short answer is because of "Set-Cookie:" headers, and quoting issues 
| with the 'expires' parameter.  The slightly longer answer is that it 
| gives the application more control of the response, which may be 
| important to work around bugs in browsers, caches, and proxies currently 
| deployed in the field.  :(

You are, of course, referring to the horribly old Netscape Specification
for Set-Cookie, http://wp.netscape.com/newsref/std/cookie_spec.html.
I'd like to note that RFC 2109 (1997), and RFC 2965 (2000) have no such
problems.  Just about every major browser out there supports max-age
parameter instead of "Expires".  Doing a quick "unofficial" survey of 
major websites, 'max-age' usage (RFC 2109) is the most common usage,
as it is far easier for server implementations to specify an age in 
seconds rather than compute a GMT timestamp. 

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.

On Sat, Dec 24, 2005 at 11:48:39PM -0500, James Y Knight wrote:
| On Dec 24, 2005, at 10:45 PM, Clark C. Evans wrote:
| >Why is response_headers a list instead of a dict?
| >
| >[ RFC quote ]
| >
| >In other words: (a) order does not matter
| 
| True, order between headers does not matter.

Yes, however, the HTTP/1.1 specification explicitly suggests that
general headers come first, then request/response headers, followed by
entity headers.  It also recommends that headers take a "common form"
when sent by servers (that is, in Camel-Dash-Case, except ones like ETag
or WWW-Authenticate). 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.

| >(b) it is reasonable to
| >restrict a header field to a single (header_name, header_value) pair.
| 
| Yes, the RFC says that, and I certainly wish it were true, but it's  
| simply not. The RFC lies. The primary example is the Set-Cookie  
| header, which by _definition_ cannot be combined, as it uses an  
| unquoted date which includes a comma.

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.

| Also, multiple WWW-Authenticate  
| headers should be okay to combine, but I've heard rumors of UAs being  
| confused by that format.

First, there is _nothing_ preventing a Server (such as Zope or Twisted)
handling this case by splitting out comma-separated WWW-Authenticate or
Set-Cookie (RFC 2109, or even the _broken_ netscape spec with a very
small amount of code) into mutltiple lines.

Second, is combination of needing _multiple_ WWW-Authenticate headers on
that particular User-Agent a real-live use case? 

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.

| WSGI could have spec'd a dictionary of lists of strings, rather than  
| a list of strings, but it did not. You can transform the result into  
| that if you like...

Well, I agree it should have been a dictionary (with lower-case keys).
I don't think that a list would have been helpful; 90% of the time
you're dealing with something that isn't a list.  And when it is a list,
appending ",mystuff" to the list isn't that hard.

Kind Regards,

Clark