[Web-SIG] Re: Bill's comments on WSGI draft 1.4

[Bill Janssen]

> The restriction that isinstance(environ, dict) be true isn't much of a 
> requirement at all, because subclasses of dictionaries can override 
> pretty much everything they care to.  If isinstance was the only 
> requirement, it might as well be required that the environment has a 
> dictionary interface.

Except that "a dictionary interface" is very poorly defined, while the
isinstance check is very well defined.  But this is a small point; I
won't argue it further.

> > Here's a scenario for you: I want to return a valid HTTP header that
> > your WSGI layer doesn't allow!  For example, accented Latin-1
> > characters, which are valid in the Reason-Phrase.  Or for another
> > example, a multi-line header value, which I actually use quite a bit,
> > and which is perfectly valid in HTTP, and which your prohibition on
> > control characters in header values breaks.
> 
> Is an accented Latin-1 character a control character?  I would have 
> though a control character meant a character with a code less than 32.

You're right.  I was confusing the requirements on headers with the
"status" argument, which is unnecessarily restricted to ASCII.

> Because it requires more work to parse and manipulate a more permissive 
> standard.  You have to worry about corner cases.

How much more work?  Why is this restriction in particular a good one?

> There's no crippling, it [streaming] is specifically allowed for.  It's not the 
> primary interface that frameworks require, so Phillip wants to encourage 
> those framework to use the iterable when they can.

Why?  Why is an editorial opinion in the technology spec?  And, which
frameworks are you talking about?  Isn't this on the "server" or
"socket" side of things, rather than the "application" or "plug" or
"framework" side of things?

Bill