How to determine what caused mod_pagespeed filter not to change page

[Marcus Hietala]

I was wondering what is the best way to debug/know why a particular
mod_pagespeed filter didn't make changes to a html page it was applied
to? And I'm especially interested is to know if this lack of change is
because the html page was not supposed to be changed and the filter
behaved as expected or because I made some mistake when configuring
mod_pagespeed or my patch to the mod_pagespeed source broke it. My
patch is very minor in nature.

What status message/string should I look for in the apache log file to
know if the filter was properly applied or bailed out due to some
problems encountered? Are there cases when badly written HTML can
cause mod_pagespeed filters not to be applied?

In my case I have combine_css enabled and the html page has several
really small css files but no matter how many times I hit the website
the css files are never combined. The css files also have cache
headers - Cache-control: max-age:720.

I suppose you have had similar issues at least occasionally while
working on developing mod_pagespeed.

In the documentation I see that combine_css and combine_js might not
be applied if the files are in different flush windows. Is there a way
to know which files fall in different flush windows other than try to
figure it out while running under control of gdb?

Thanks a lot for your help.

Best,
Marcus

[Joshua Marantz]

We don't get a lot of "how do I hack the code" questions!  We've mostly been using the debugger (use httpd -X) or better yet, unit-tests (see css_combine_filter_test.cc).

You can also add "loglevel debug" to httpd.conf in a test server and look at all the logs; depending on the filter there may be some hints there.  You can cross-correlate with code or add more logging there.  There are some logging calls you can find in various filters & copy that code.

-Josh