httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Marantz <jmara...@google.com>
Subject Re: output filter ordering question: mod_deflate vs mod_headers vs mod_pagespeed
Date Thu, 17 May 2012 15:36:39 GMT
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 <jmarantz@google.com> 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 <niq@apache.org> 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
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message