[Web-SIG] PEP 333 and gzipping of responses
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
> 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 , 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...
More information about the Web-SIG