[Web-SIG] WSGI 2.0

Graham Dumpleton graham.dumpleton at gmail.com
Fri Apr 6 04:52:25 CEST 2007

On 06/04/07, James Y Knight <foom at fuhm.net> wrote:
> On Apr 5, 2007, at 10:08 PM, Graham Dumpleton wrote:
> > FWIW, in mod_wsgi I have now added a directive which allows one to
> > enable within a specific context that chunked transfer encoding should
> > be used for a response when a HTTP/1.1 client is being used. Thus, if
> > you know the content generated from a resource at a particular URL
> > within your application would benefit from chunked transfer encoding
> > on the response, you could use:
> >
> >   <Location /mysite/some/resource>
> >   WSGIOutputChunking On
> >   </Location>
> >
> > At this stage is probably better than nothing given that WSGI doesn't
> > provide a way of enabling it.
> What's the point of a switch? If the app didn't provide a content-
> length, and you can't otherwise determine a content-length (because
> for example the result is a simple list of strings), just do chunked
> encoding output automatically.

To a degree that may make sense, but to my mind, the implementation of
a lower level layer beneath the application, which an application
writer may have little real control over, should not really be making
an arbitrary decision on behalf of the user to impose such a
behaviour. It should always be up to the application writer to make
the decision.

That said, it may be worthwhile to actually implement the directive to
honour Off (default), On or Auto. Thus On is always use chunked
transfer encoding and Auto would be what you describe. Which approach
is used though should still be the application writers choice.

One good thing your comment highlights is that when we come to working
out how in future WSGI specification an application could control use
of chunked transfer encoding, that a simple On and Off may not be
enough and that having an Auto like switch may also be advantageous in
certain cases.


More information about the Web-SIG mailing list