[Web-SIG] Re: Latest WSGI Draft (Phillip J. Eby)

[tony at lownds.com]

>>In the meantime, I'm fine with headers remaining as they were in the
>>previous draft: i.e. a sequence of tuples.
>

+1

> Hm.  Looking at 'email.Message', actually, it has all the semantics needed
> for header management, and it looks like the interface at least is stable
> across 2.2 and 2.3 (I haven't checked 2.4.)
>
> The code is relatively brief, and I think I'd be okay with using it as the
> type for 'headers'.  Anybody have any objections?  Here's sample usage:
>

It's a nice idea, and it would probably simplify both server and
application code
and the spec. But, it forces an implementation. I think inclusion in the
PEP as a possible
change before 1.0, will give the idea plenty of discussion time.

>      from email.Message import Message
>
>      def application(env, start):
>          headers = Message()
>          headers.set_type("text/plain")
>          headers.add_header("Set-Cookie", "CUSTOMER=WILE_E_COYOTE",
> path="/foobar")
>          start("200 OK", headers)("Hello world!")

Just call the items() method, and WSGI remains the same

          start("200 OK", headers.items())("Hello world!")

>
> One of the nice things about it is that it makes it easier to do MIME and
> HTTP headers that have parameter info.
>

One issue: after the m.set_type call, an extra MIME-Version: 1.0 header is
present.
According to the HTTP 1.1 spec, when that header is present, whatever the
server sends must be in "full compliance" with the MIME protocol. From
reading the MIME spec, I guess adding Content-transfer-encoding: binary
would take care of that...

-Tony