Author orsenthil
Recipients abacabadabacaba, antialize, eric.araujo, jcea, jjlee, nadeem.vawda, orsenthil, ruseel, serhiy.storchaka, thomaspinckney3
Date 2012-06-25.10:53:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340621625.85.0.432705916638.issue1508475@psf.upfronthosting.co.za>
In-reply-to
Content
I think, the transparent compression should work at http.client level. I also agree with other points made by Serhiy:

- transparent decompression should delete headers Content-Encoding and Content-Length (this is as per RFC too)

- Should not do another compression if the user has a explicit specified intent of using Content-Encoding: gzip and is ready to do decompression himself.

- This transparent compression/decompression would require the availability gzip module, if not then the feature may be disabled and normal request-response cycle would proceed.

- I think, having it 'ON' with a flag to switch 'OFF' would be more desirable than having this feature via Handler. The reason being it can help in performance of any requests on servers that support it and browsers have adopted similar approach too.
History
Date User Action Args
2012-06-25 10:53:45orsenthilsetrecipients: + orsenthil, jjlee, jcea, antialize, ruseel, nadeem.vawda, thomaspinckney3, eric.araujo, abacabadabacaba, serhiy.storchaka
2012-06-25 10:53:45orsenthilsetmessageid: <1340621625.85.0.432705916638.issue1508475@psf.upfronthosting.co.za>
2012-06-25 10:53:45orsenthillinkissue1508475 messages
2012-06-25 10:53:45orsenthilcreate