HstFilter may want to proceed with the next filter chain after processing sitemap handlers.

Currently, if sitemap handlers were configured for a sitemap item and the sitemap handlers return null, then HstFilter does nothing.

In this model, if a sitemap handler wants to handle the request and render something as a custom extension, then the sitemap handler is supposed to return 'null' after its custom rendering.
However, we might want to support another case where a sitemap handler returns null and let the other remaining servlet filter handle the request.

For example, let's suppose we have a wicket filter application (/customer/*) which we want to keep as a custom extension for the hst application. We can configure a sitemap item (/customer/_any_) and configure a custom sitemap item handler, which just does something like setting content document bean into request object and wants to let the existing wicket application do the remaining.

Of course it might be still possible for the sitemap item handler to dispatch the request by including to the remaining wicket filter, but it's not so convenient because the wicket filter mapping configuration should be changed to include <dispatcher>INCLUDE</dispatcher> element in web.xml.

So, what I'm thinking is that it might more convenient if HstFilter can process the filter chain by invoking filterChain.doFilter(request, response) for the case when a sitemap item handler wants. Then, the sitemap handler does only what it has to do and let the existing application (such as wicket filter application) do the proper things (such as page rendering).