On Mon, Aug 10, 2009 at 9:11 PM, James Bennett <span dir="ltr"><<a href="mailto:ubernostrum@gmail.com">ubernostrum@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Earlier today I posted an article on my blog following up on some<br>
discussions of WSGI; one criticism presented was of language in PEP<br>
333 regarding gzipping of responses by WSGI applications. Ian posted a<br>
comment which stated that the criticism was not correct, but I'm at a<br>
loss to figure out what *is* correct, so I'll bring up the question<br>
here.<br>
<br>
In a parenthetical at the end of the section entitled "Handling the<br>
Content-Length Header", PEP 333 states:<br>
<br>
> Note: applications and middleware must not apply any kind of<br>
> Transfer-Encoding to their output, such as chunking or gzipping; as<br>
> "hop-by-hop" operations, these encodings are the province of the<br>
> actual web server/gateway. See Other HTTP Features below, for more<br>
> details.<br>
<br>
In the section "Other HTTP Features", PEP 333 states, in part:<br>
<br>
> However, because WSGI servers and applications do not communicate<br>
> via HTTP, what RFC 2616 calls "hop-by-hop" headers do not apply to<br>
> WSGI internal communications. WSGI applications must not generate<br>
> any "hop-by-hop" headers [4], attempt to use HTTP features that<br>
> would require them to generate such headers, or rely on the content<br>
> of any incoming "hop-by-hop" headers in the environ dictionary.<br>
<br>
My criticism of this is that this is at best ambiguous, and quite<br>
possibly openly misleading to readers of the PEP.<br>
<br>
The ambiguity here is that "gzip" is a valid value for the<br>
Transfer-Encoding header in HTTP (RFC 2616, Sections 3.6 and 14.41),<br>
but is also a valid value for the Content-Encoding header (RFC 2616,<br>
Sections 3.5 and 14.11).<br>
</blockquote><div><br></div><div>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?</div>
<div><br></div><div>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.</div>
</div><br>-- <br>Ian Bicking | <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a> | <a href="http://topplabs.org/civichacker">http://topplabs.org/civichacker</a><br>