Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of jmarantz@google.com
 designates 216.239.44.51 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=google.com; s=beta;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=rfmpbr4c5HK0VbIaH136BNoRmx1JVOWw7FYLsahi94TyKGJS6HqmX6ZpQ3az5z+sr1
         hZgCGfGfXqZ0RQwz3HsQ==
MIME-Version: 1.0
In-Reply-To: <AANLkTimBGvBQh-ty-Wh3mQor-=iXEZusDdBsPCGMUg8f@mail.gmail.com>
References: <AANLkTin_pgptHtrMg0V3YGaodM2rWPiWbYgsd2n1uFT+@mail.gmail.com>
 <AANLkTimdxudk0G_6w7-2Q3Lq3m-iOy5LK399YrRv2ZSw@mail.gmail.com>
 <AANLkTinpWCgVzrXzitar7ffscbok4RVHAjnBiUB4KjQX@mail.gmail.com>
 <AANLkTimBGvBQh-ty-Wh3mQor-=iXEZusDdBsPCGMUg8f@mail.gmail.com>
From: Joshua Marantz <jmarantz@google.com>
Date: Wed, 5 Jan 2011 14:40:35 -0500
Message-ID: <AANLkTikiWRoJrRn+jCZP3WeEY0tF_nnSUhtm2H9z9XqH@mail.gmail.com>
Subject: Re: Help trying to figure out why an output_filter is not called.
To: modules-dev@httpd.apache.org
Content-Type: multipart/alternative; boundary=002215048fb748f09e04991e90c5

--002215048fb748f09e04991e90c5
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 5, 2011 at 10:43 AM, Ben Noordhuis <info@bnoordhuis.nl> wrote:

>  > I guess we should eliminate FIXUP_HEADERS_OUT, FIXUP_HEADERS_ERR, and
> > MOD_EXPIRES.
>

 Are there any other similar header-mucking-filters I need to kill?

 > Moreover, expires_insert_filter runs as APR_HOOK_MIDDLE which means it
> runs
> > after my content-generator, which means that it won't have been inserted
> by
> > the time when I want to set my caching headers.
>
> You can remove it from your handler, scan
> r->output_filters->frec->name to find the filter.
>

I'm not following you.  mod_expires.c has this:

static void expires_insert_filter(request_rec *r) {
  ...ap_add_output_filter("MOD_EXPIRES", NULL, r, r->connection);...
}

static void register_hooks(apr_pool_t *p) {
    /* mod_expires needs to run *before* the cache save filter which is
     * AP_FTYPE_CONTENT_SET-1.  Otherwise, our expires won't be honored.
     */
    ap_register_output_filter("MOD_EXPIRES", expires_filter, NULL,
                              AP_FTYPE_CONTENT_SET-2);
    ap_hook_insert_error_filter(expires_insert_filter, NULL, NULL,
APR_HOOK_MIDDLE);
    ap_hook_insert_filter(expires_insert_filter, NULL, NULL,
APR_HOOK_MIDDLE);
}

So if I try to remove the 'expires' filter from my handler (which runs
early) then mod_expires will have a handler that runs later that inserts it
after my module has completed.  Hence:

> I guess that means I have to insert a new late-running hook that kills
> > undesirable output filters.  Does that wind up being simpler?
>
> The above is probably easier but whatever ends up being the most
> readable / maintainable, right?
>

And also functional :) which, evidently, my current solution is not, at
least in the presence of mod_perl and mod_php.

Your solution has the advantage of being more robust when upstream filters
write directly to the network.  I just wish I didn't have to depend on my
copies of string literals from .c files I don't control.  But as you said
core-filters will hopefully not change internal string constants often.   I
just coded it up and it seems to work :)

-Josh

--002215048fb748f09e04991e90c5--