[Web-SIG] PEP 333 and gzipping of responses

Ian Bicking ianb at colorstudy.com
Tue Aug 11 06:50:22 CEST 2009

On Mon, Aug 10, 2009 at 9:11 PM, James Bennett <ubernostrum at gmail.com>wrote:

> Earlier today I posted an article on my blog following up on some
> discussions of WSGI; one criticism presented was of language in PEP
> 333 regarding gzipping of responses by WSGI applications. Ian posted a
> comment which stated that the criticism was not correct, but I'm at a
> loss to figure out what *is* correct, so I'll bring up the question
> here.
> In a parenthetical at the end of the section entitled "Handling the
> Content-Length Header", PEP 333 states:
> > Note: applications and middleware must not apply any kind of
> > Transfer-Encoding to their output, such as chunking or gzipping; as
> > "hop-by-hop" operations, these encodings are the province of the
> > actual web server/gateway. See Other HTTP Features below, for more
> > details.
> In the section "Other HTTP Features", PEP 333 states, in part:
> > However, because WSGI servers and applications do not communicate
> > via HTTP, what RFC 2616 calls "hop-by-hop" headers do not apply to
> > WSGI internal communications. WSGI applications must not generate
> > any "hop-by-hop" headers [4], attempt to use HTTP features that
> > would require them to generate such headers, or rely on the content
> > of any incoming "hop-by-hop" headers in the environ dictionary.
> My criticism of this is that this is at best ambiguous, and quite
> possibly openly misleading to readers of the PEP.
> The ambiguity here is that "gzip" is a valid value for the
> Transfer-Encoding header in HTTP (RFC 2616, Sections 3.6 and 14.41),
> but is also a valid value for the Content-Encoding header (RFC 2616,
> Sections 3.5 and 14.11).

I just don't get the confusion.  Transfer-Encoding is not allowed in WSGI (a
hop-by-hop header, like several other Transfer-* headers).  Content-Encoding
is allowed, because everything not specifically mentioned is allowed.
 Clearly "Content-Encoding" and "Transfer-Encoding" are different strings.
 And, as you mention, the normal thing that people currently do is use
Content-Encoding anyway, so since people aren't using Transfer-Encoding, why
is this controversial?

There are some weird implications to using Content-Encoding, specifically
ETags and range requests, but eh... those exist in mod_deflate and just
about everywhere, and are mostly outside the scope of WSGI.

Ian Bicking  |  http://blog.ianbicking.org  |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20090810/934a1193/attachment.htm>

More information about the Web-SIG mailing list