Re: mod_deflate - disabling per response?

[Jess Holle]

Geoffrey Young wrote: Jess Holle wrote: My apologies if this is better done on the user group, but I've been reading Apache source code and trying to understand the following. Is there any way to signal mod_deflate that a particular response should not be deflated when: 1. the URL of the request is identical to other cases that should be deflated, 2. the MIME type of the response is identical to other cases that should be deflated, and 3. the response is not already compressed/deflated? Essentially request parameters, data states, Java server logic, etc, behind mod_jk (or mod_jk2) will dictate whether compression can be allowed, but I need a way to signal this in my response from Tomcat. Any pointers would be much appreciated! really, it's the client that decides whether the content should be encoded or not, which they typically do by setting an Accept-Encoding request header. so remove that in the client and no compression. Normally, yes. My specific case is one where client timeouts are prevented through periodic whitespace output with flushes (in HTML responses) when the server knows it has been thinking too long. One might debate the wisdom of that strategy -- but it is pre-existing. Thus either I exclude the URLs that might show this behavior from the mod_deflate filtering (thus excluding a lot of other cases where mod_deflate *should* be used) or I find a way to signal "don't deflate me" in such responses. from the server side, it looks like you can set use the subprocess_env table to suppress it if you have access to the API apr_table_setn(r->subprocess_env, "no-gzip"); not sure if either of these suits you, though. Hmmm...  What I'm really looking for is a response header or some such that I can set in my JSP page or servlet in Tomcat to indicate that the response should be left alone.... -- Jess Holle