Major Description
I see two improvements to FilteringHeaderResponse:
1) FilteringHeaderResponse requires a name for the filter that should be used for contributions in the <head>. Since the value of this filter name is custom FilteringHeaderResponse can provide constructor which provides default name for this filter
2) If a HeaderItem is not accepted by any of the configured filters then the item is simply dropped and a warning message is logged. It will be much more friendlier if the item is rendered in the <head> as in the case when non-filtering header response is used. The application should not be forced to provide filter for this explicitly.