[Web-SIG] Re: Bill's comments on WSGI draft 1.4
Phillip J. Eby
pje at telecommunity.com
Mon Sep 6 15:23:59 CEST 2004
[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
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
> > 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.
More information about the Web-SIG