On Thu, Oct 25, 2012 at 9:20 PM, Jeff Rogers <dv...@diphi.com> wrote: > It looks like we're enabling compression for all http/1.1 requests > regardless of whether it was specified in the request header, or even > specifically disallowed. This seems incorrect, but the code has been in > place for several years (connio.c:CheckCompress) ; is there a reason > not to change that?
I think the spec says that for HTTP/1.1, if the client doesn't explicitly say to NOT send the body gzipped, say by using a q value of 0 (which we don't actually check for, woops...), then the server can choose the encoding, although it should prefer the identity, unless that's unavailable. So we're being very pushy... There's a bunch of tests for this in tests/ns_adp_compress.test, including with and without the Accept-Encoding header and q values, but many of them are disabled with -constraints knownBug. I guess it's something someone thought about but no one got round to fixing it. This page describes how to run these particular tests: http://wiki.tcl.tk/21659 > Also on compression, a separate compression stream is pre-allocated and > initialized for each pre-allocated Conn, whether or not compression is > even enabled for the server. The causes a fairly large initial memory > footprint. I think this pre-initialization could be made optional, and > bypassed entirely when compression isn't enabled. Any thoughts? Seems reasonable. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
