Hi I gave it a try but need a little help to get further.
I added this to my configuration file:
FilterDeclare headers CONTENT_SET
FilterDeclare pagespeed CONTENT_SET
FilterDeclare deflate CONTENT_SET
FilterProvider pagespeed MOD_PAGESPEED_OUTPUT_FILTER resp=Content-Type
$text/html
FilterProvider headers FIXUP_HEADERS_OUT resp=Content-Type $text/html
FilterProvider deflate DEFLATE resp=Content-Type $text/html
FilterChain headers pagespeed deflate
However when I look at the request in an early output-filter I see this:
pagespeed: AP_FTYPE_CONTENT_SET(0)
deflate: AP_FTYPE_CONTENT_SET(0)
fixup_headers_out: AP_FTYPE_CONTENT_SET(0)
byterange: AP_FTYPE_PROTOCOL(0)
content_length: AP_FTYPE_PROTOCOL(0)
http_header: AP_FTYPE_PROTOCOL(0)
http_outerror: AP_FTYPE_PROTOCOL(0)
log_input_output: AP_FTYPE_NETWORK(-1)
core: AP_FTYPE_NETWORK(0)
The code that printed this is:
void PrintFilterChain(ap_filter_t* filter) {
// TODO(jmarantz): debug-check that these are in increasing order.
static ap_filter_type types[] = {
AP_FTYPE_RESOURCE, AP_FTYPE_CONTENT_SET, AP_FTYPE_PROTOCOL,
AP_FTYPE_TRANSCODE, AP_FTYPE_CONNECTION, AP_FTYPE_NETWORK
};
static const char* type_names[] = {
"AP_FTYPE_RESOURCE", "AP_FTYPE_CONTENT_SET", "AP_FTYPE_PROTOCOL",
"AP_FTYPE_TRANSCODE", "AP_FTYPE_CONNECTION", "AP_FTYPE_NETWORK",
"END"
};
static ap_filter_type* types_end = types + arraysize(types);
for (ap_filter_t* next; filter != NULL; filter = next) {
next = filter->next;
// Get the symbolic name for the filter's position, relative to the
// symbolic constants above.
ap_filter_rec_t* frec = filter->frec;
ap_filter_type type = frec->ftype;
ap_filter_type* pos = std::lower_bound(types, types_end, type);
int index = pos - types;
int delta = static_cast<int>(type) - static_cast<int>(*pos);
fprintf(stdout, "%s: %s(%d)\n", frec->name, type_names[index], delta);
}
fflush(stdout);
}
Is the filter ->next chain not the correct way to look at this data? In
any case the evidence from my system-tests suggest that I haven't achieved
the ordering I want yet. Is there something else I need to do?
On Thu, May 17, 2012 at 9:27 AM, Joshua Marantz <[email protected]> wrote:
> Thanks for the quick reply, Nick. I played around with this idea but
> couldn't get it to work. My filter now runs at
> AP_FTYPE_CONTENT_SET + 1, to make sure it runs after mod_headers. I don't
> know how to try to coax mod_deflate to run after me. I can prevent it from
> running before me by removing it from the filter-chain in before my main
> filter-function runs, but when I try to then put it back in the filter
> chain after my main filter function, it doesn't appear to work. But you
> are right; this is a hack on a hack and perhaps not worth pursuing further.
>
> Is mod_filter a mechanism I could use in Apache 2.2 to accomplish what I
> need? I found http://httpd.apache.org/docs/2.2/mod/mod_filter.html and
> it looks promising. I'll give it a try.
>
> The tone of your email made it sound like mod_filter is not quite ready,
> but it's there in my distribution. Can you elaborate on the state of
> mod_filter?
>
> Thanks!
> -Josh
>
> On Thu, May 17, 2012 at 2:30 AM, Nick Kew <[email protected]> wrote:
>
>>
>> On 17 May 2012, at 04:24, Joshua Marantz wrote:
>>
>> > Or is that insane &/or dangerous?
>>
>> AP_FTYPE_ values are something of a blunt instrument, not ideal
>> for cases where you care about ordering. Running mod_headers
>> as a filter is a bit of a hack. What you're proposing is kind-of building
>> a hack onto a hack. I'm sure you can make it work (at least in
>> controlled circumstances where you're not competing against
>> other similar fudges) but IMHO you're right to be worried.
>>
>> Having once upon a time written mod_filter to deal with more
>> complex configuration than the original design envisaged,
>> I wonder if your issue might be a hint that we should
>> revisit the API for programmatic configuration, and make
>> your proposal less hackish?
>>
>> --
>> Nick Kew
>>
>
>
