On Friday 11 April 2008 16:41, Dossy Shiobara wrote: > Configuration parameters is too coarse-grained control. Ultimately, the > compression flag should be conditionally turned "on" in a registered > filter if you want it at a higher level than in the actual request > processing code, itself. (IMHO, the decision to compress a request > should be handled on a per-request basis, as not all requests > unilaterally benefit from server-side compression ... so this should be > an _intelligent_ decision that's being made by the developer whether to > compress the result or not.) > > My two cents, anyhow.
If configuration is done using a trie, like threadpools, you will have very good control. I think the main point is that ns_return is not the place to decide this, it leads to very brittle code. Also, if I remember correctly, the ns_zlib module can be configured to only compress data which is larger than some minimum number of bytes. So even with a broad compression filter, you should be able to add parameters. For instance, look at Content-Length header, if > than some amount, compress and rewrite the header and add others. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
