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

[Phillip J. Eby]

[skipping stuff that Ian answered]

At 12:47 PM 9/2/04 -0700, Bill Janssen wrote:

>I'm not familiar with all the ins and outs of files on Python and
>Jython and IronPython, so I'll just say, reasonable enough.  Though
>I'd prefer to say, a file-like object (whatever that means).

File-like is out of scope; there were only ever two kinds of objects 
intended to be returnable:

1) Iterables (the initial scope)

2) Objects that map to an operating system file descriptor, as an optional 
special case to increase performance (added later per user request)

I think that perhaps because files (under 2.2+ at least) meet *both* of 
these criteria, some folks have construed this to mean that we really 
should allow any file-like object, when "file-like" never had anything to 
do with anything.  It's a total red herring that has nothing to do with the 
spec's intent.

I will add something to the Q&A section about this.


> > These restrictions are intended to simplify servers and middleware; nobody
> > has yet presented an example of a scenario where this imposed any 
> practical
> > limitation.
>
>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.

Technically, you could use the MIME header encoding support to put them in, 
encoded in 7-bit ASCII, as is allowed by RFC 2616.

OTOH, I could see allowing 8-bit strings in ISO-8859-1 encoding as per RFC 
2616, and don't see significant practical problems in doing so.


>   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.
>
> > The fallback position would be that the status string and headers must not
> > be CR or CRLF terminated.
>
>The fallback position would be fine.

I'm currently still strongly -1 on allowing folding; the only thing that's 
going to budge me is use cases.  I only accept "on general principle" 
arguments when they *simplify* compliance and make the spec more robust, 
not when they make compliance more difficult.

Header folding adds repetitive boilerplate processing to all middleware 
that processes headers: boilerplate that can and will be written 
incorrectly or sometimes omitted because somebody forgot that headers are 
allowed to be folded.  Before too long, the practical advice to WSGI 
application authors will be, "don't fold headers because it breaks a lot of 
middleware", and we'll be right back where we could've been in the first 
place if we just banned folding from the get-go.  Meanwhile, the people who 
will have paid the price for this is all the conscientious implementors who 
tried to write code that would work properly with header folding.