[Web-SIG] WSGI 2.0

[Graham Dumpleton]

On 03/04/07, Clark C. Evans <cce at clarkevans.com> wrote:
> On Fri, Mar 30, 2007 at 11:10:17AM +1000, Graham Dumpleton wrote:
> | One other issue if aiming at supporting chunked encoding for a request,
> | is how (if one even can) make available the trailing headers if present
> | after the final null data block. Personally I am not sure this one is
> | worth the trouble and may be quite hard to even implement with some web
> | servers as they don't even provide them as a separate set of headers but
> | simply merge them on top of the main request headers.
>
> In my particular application it'd be quite helpful if I could return
> Chunked-Body responses (especially ones with additional trailing
> headers). Since WSGI rules the use of transfer encodings, then it should
> have a mechanism to request this sort of behavior aka, yield a "flush"
> object that has optional trailing headers that should be included in the
> chunk that is returned.

Do you know of any actual web servers that provide a facility for
sending trailers after the final null chunk in a response? Apache for
one doesn't provide a way of doing this:

        /* RFC 2616, Section 3.6.1
         *
         * If there is an EOS bucket, then prefix it with:
         *   1) the last-chunk marker ("0" CRLF)
         *   2) the trailer
         *   3) the end-of-chunked body CRLF
         *
         * We only do this if we have not seen an error bucket with
         * status HTTP_BAD_GATEWAY. We have memorized an
         * error bucket that we had seen in the filter context.
         * The error bucket with status HTTP_BAD_GATEWAY indicates that the
         * connection to the backend (mod_proxy) broke in the middle of the
         * response. In order to signal the client that something went wrong
         * we do not create the last-chunk marker and set c->keepalive to
         * AP_CONN_CLOSE in the core output filter.
         *
         * XXX: it would be nice to combine this with the end-of-chunk
         * marker above, but this is a bit more straight-forward for
         * now.
         */
        if (eos && !f->ctx) {
            /* XXX: (2) trailers ... does not yet exist */
            e = apr_bucket_immortal_create(ASCII_ZERO ASCII_CRLF
                                           /* <trailers> */
                                           ASCII_CRLF, 5, c->bucket_alloc);
            APR_BUCKET_INSERT_BEFORE(eos, e);
        }

Note the comment that step 2, sending of trailers doesn't yet exist.

So even if WSGI had a way of supplying trailers, I doubt there would
be many WSGI adapters for web servers that could actually implement
it.

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.

Graham