> 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
I assume you want to be able to add a response header from your
back-end that looks something like this...
X-Do-not-compress-this: Dummy_value
mod_deflate has no such pickup at this time... but you
can easily just add this yourself.
Just take a look at ../modules/filers/mod_deflate.c
At the point where 'deflate_out_filter()' kicks in you have
access to both the input (request) headers and the output
(response) headers so you can pretty much do whatever you want.
The routine is already checking for things in both the input
and output headers with (actual) statements like...
accepts = apr_table_get(r->headers_in, "Accept-Encoding");
encoding = apr_table_get(r->headers_out, "Content-Encoding");
You can just add your OWN check right there amongst the
other 'checks' and shut down the filter based on whatever
criteria you like.
Here are the actual 4 lines of code that will 'shut down'
the compression filter if it doesn't see 'Accept-Encoding'
in the input (request) header(s)...
[snip]
/* if they don't have the line, then they can't play */
accepts = apr_table_get(r->headers_in, "Accept-Encoding");
if (accepts == NULL) {
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, bb);
}
[snip]
All you would have to do is just copy these 4 lines of code
right underneath where they appear and just make
a few little changes...
[snip]
/* If a back-end server tells us not to compress this response then OBEY... */
if ( apr_table_get(r->headers_out, "X-Do-not-compress-this") ) {
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, bb);
}
[snip]
That's it. You don't even need a scratch pointer to do this since
all you would be doing is checking for the presence of the
special 'X-Do-not-compress-this:' header coming from the back-end
server. The 'Dummy_value' doesn't matter. It only matters if the
header itself is present. If it has an 'X-' on the front then you don't even
need to worry about removing it. Just leave it there and all downstream
proxies and agents SHOULD 'ignore it'.
Actually... a good case could be made for leaving it there in case
someone gripes about something not getting compressed when
they think it should. If the header makes it all the way back to
the 'griper' then there is no doubt what 'happened'... it was
specifically EXCLUDED from being compressed and it was
not 'an accident' or 'a bug'... it's a 'feature'.
If you wanna get fancy you could do this...
[snip]
/* If a back-end server tells us not to compress this then OBEY... */
no-compress = apr_table_get(r->headers_out, "X-Do-not-compress_this");
if ( no-compress ) {
apr_table_unset(r->headers_out, "X-Do-not-compress-this");
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, bb);
}
[snip]
If you go this route be sure to add the 'scratch pointer'
named 'no-compress' to the stack variables declared at
the top of the function...
This...
if (!ctx) {
char *buf, *token;
const char *encoding, *accepts;
...Would need to have your 'scratch' pointer added to it like this...
if (!ctx) {
char *buf, *token;
const char *encoding, *accepts, *no-compress;
This line...
apr_table_unset(r->headers_out, "X-Do-not-compress-this");
...will search the output headers for all headers matching
this string and will REMOVE them from the output header(s).
Caveat: See notes above about good reason(s) to actually LEAVE
the 'X-Do-not-compress-this:' header there if/when it is used.
BTW: mod_gzip for the Apache 1.2.x series and above has
always had the ability to do this sort of thing.
You can always 'control' what is or isn't getting compressed
with simple configuration commands like...
mod_gzip_item_exclude rspheader "X-Do-not-compress-this: *"
That single mod_gzip configuration line accomplishes the same
purpose as the code shown above.
If a RESPONSE header appears ( from the back-end or wherever )
named 'X-Do-not-compress-this:' or whatever ( totally up to you
and defined in the config ) and it has any kind of 'value' at all
then it will match the STAR regular _expression_ search and the
the response will excluded from compression.
mod_deflate will certainly ( at some point ) need better
configuration-based control over the decision making process
than it currently has.
I hope this has been of some help.
No one else seemed to be responding so I thought I would put
my 2 cents in.
Yours...
Kevin Kiley
In a message dated 3/5/2004 1:35:35 PM Central Standard Time, [EMAIL PROTECTED] writes:
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
