Igor Vaynberg wrote:
erm no
the important thing is that what we do is set the 404 header
that way the filter chain knows its a 404 and can handle it properly
as opposed to us happily streaming our own error page with a 200
Errr, no. :-) We don't want to stream anything at all in the filter
chain case.
Currently WicketFilter looks to see if things match a Wicket
page/request with isWicketRequest() (line 118 on WicketFilter) and
leaves it the hell alone if it doesn't. Don't you go changing that to
serve a 404 instead, or everyone's other servlet mappings and static
resources and things will break.
You can modify doGet() to serve a 404, that's fine. By that point, the
filter thinks it's a Wicket request, so you probably should.
In the filter case, one can achieve all this by mounting a 404 page, and
using <error-page> to point to it. It certainly seems to cover all my
use cases, and that way you can serve the same 404 page for non-Wicket
URLs. I don't think you ever get 404 pages if something has passed the
isWicketRequest() check.
Al
