On 26.10.12 15:47, Stephen Deasey wrote: > 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... now we do check for the qvalues used in connection with gzip. So, a client can now specify explicitly, that gzip is NOT wanted via "gzip; q=0". What the code still does not do is comparing the identity-qvalue with the gzip-qvalue or combination with wildcards "....*;q=..."
>> 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. the initialization is on the server level during startup for every connection structure, the actual need comes up in a connection thread. One could defer the Ns_CompressInit until a connection thread needs it (by checking, whether the compress stream is available/initialized. -gustaf neumann ------------------------------------------------------------------------------ WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
