On Aug 9, 2013, at 11:09 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> Historically, we haven't updated our documentation to point out bugs, but in > this case, given that there are ongoing security implications, I think it > might be worthwhile to draw attention to this. I agree with documenting. > > I also have a nagging feeling in the back of my head that there have been > questions raised about whether GZIPMiddleware should exist *at all* -- that > there's some niggling detail in the WSGI spec that says that GZip compression > should be applied at the web server level, not the WSGI level. Can anyone > confirm if I'm hallucinating on this point? And if I'm not, perhaps we should > just be deprecating GZipMiddlware? This is an interesting question. You are right that the WSGI spec states that and historically I would have agreed with you. However in light of the recent BREACH vulnerability I have a sneaking suspicion that compression is going to move down the stack into the application layer. Unless a more generalized solution is created I believe that the ability to turn compression on and off at the application level is going to be important. The application knows what *kind* of data exists in a response body and wether or not it is safe to compress it. The web server does not (except by crude heuristics such as path). ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
