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

[Phillip J. Eby]

At 08:05 AM 8/25/04 -0700, tony at lownds.com wrote:
> >>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.

But it's available in the standard library, and therefore will be *one* 
implementation, and thus have only one set of bugs to work around per 
Python version.  :)



>Just call the items() method, and WSGI remains the same
>
>           start("200 OK", headers.items())("Hello world!")

Quite so.  But turning the items back into headers is more complex, if 
middleware wants to manipulate them, e.g.:

     for n,v in headers:
         msg.add_header(n,v)

In any case, email.Message is actually a very thin wrapper over a list of 
name,value pairs!  It just provides the needed functionality to manipulate 
the headers.


>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...

We could require the server to add a c-t-e header if it's missing and 
MIME-Version is present, i.e.:

     if ('MIME-Version' in headers and
         'Content-Transfer-Encoding' not in headers
     ):
         headers['Content-Transfer-Encoding'] = "whatever"