|
Ben Bangert wrote:
> Indeed. First, this is one of the reasons that the PEP
> actually says middleware should never alter the
> transfer-encoding. While I've seen several gzip
> middleware's out there, the WSGI PEP actually outlaws
> these (the end of the content-length section):
> http://www.python.org/dev/peps/pep-0333/#handling-the-content-length-header
Not true. The PEP "outlaws" only transfer-codings (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5), not content-codings (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6). The reason it does so has nothing to do with namespace or feature collisions--it's the fact that only the origin server deals with HTTP "hops", and the WSGI conversation is not an HTTP conversation. I haven't seen a single piece of middleware that sets transfer-codings. The ones that gzip as a content-coding are just fine and aren't "outlawed" at all.
Robert Brewer
System Architect
Amor Ministries
fumanchu amor.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---
|