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

[Phillip J. Eby]

(Tony: I'm assuming this was intended for web-sig; discussions like this 
should be archived "for the record".  I hope that's not an issue for you.)


At 09:22 AM 8/25/04 -0700, tony at lownds.com wrote:
> >
> >>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)
> >
>
>Yes, that is an advantage. But applications with their own header
>manipulation library would need to do that as well, if a Message()
>instance was required.

But how many of those applications currently use a list of key,value pairs 
as their data structure?  They're going to have to loop over whatever they 
actually use, or build it up piece by piece, or do whatever it is that they do.

I'm pretty much assuming that current apps/frameworks will need to generate 
a 'headers' structure, so as long as it's a simple loop, it doesn't much 
matter what goes in the body of that loop.

Also, frameworks are usually going to have only one place to create WSGI 
headers, but middleware is by definition intended to be stacked.  And, it's 
more likely that a single author will write multiple middleware components, 
than WSGI wrappers for multiple frameworks.  So, simplifying the job of 
middleware authors, if it doesn't significantly burden framework authors, 
is a good thing here, I think.  (Since the only framework authors who would 
be burdened by the change are those who already use  a precisely compliant 
data structure; everyone else had to write a loop anyway.)


> > 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"
> >
> >
>
>I think that warning applications about this implication of set_type would
>be sufficient.
>
>Content-transfer-encoding is assumed to be 7bit if not present, its not
>required by MIME. 7bit would be wrong for a lot of HTTP responses though.

In the current spec, the server is already required to ensure validity of 
the headers; this would just be a specific mention of one example of that.