Thanks for all the responses. I haven't tried to reproduce this at all -- this shows up on a site with a back-end infrastructure that I don't have access to (e.g. PHP scripts).
But I'm inclined to go with Ben's suggestion of removing the mod_headers filter (and also I think mod_expires) whenever I don't want my headers messed with. It has the virtue of leaving the headers in the correct state in case a filter downstream to mine goes directly to the net, compared with my current dependence on a late-running repair filter. -Josh On Wed, Jan 5, 2011 at 11:14 AM, Nick Kew <n...@apache.org> wrote: > On Wed, 5 Jan 2011 08:45:57 -0500 > Joshua Marantz <jmara...@google.com> wrote: > > > > What might be going wrong in his server to cause this to fail? Could > some > > other filter be somehow finding our filter and killing it? Or sending > the > > bytes directly to the network before our filter has a chance to run? > > Yes. Any of the above. Someone may be breaking modularity. > PHP has a track record of that, and from your recent posts here > I'd guess it's not the only suspect. > > Can you reproduce the problem? If so, run it under a debugger or trace > and look for when your filter is inserted and whether it's removed. > Does mod_diagnostics tell you anything if you run it at the same level > as yours? > > -- > Nick Kew >
