Dispatcher breaks on kvp parse when strict=true is used

What's happening is that submitting whatever GetFeature request to the .../wfs?strict=true results in the following stack trace:

25 giu 12:32:29 WARN [geoserver.ows] -
org.geoserver.wfs.WFSException: The query should specify either typeName or a featureId filter
at org.geoserver.wfs.kvp.GetFeatureKvpRequestReader.read(GetFeatureKvpRequestReader.java:122)
at org.geoserver.ows.Dispatcher.parseRequestKVP(Dispatcher.java:1014)
at org.geoserver.ows.Dispatcher.dispatch(Dispatcher.java:385)
at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:185)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:357)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1054)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:170)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:47)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:358)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:629)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:453)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
at org.mortbay.jetty.Server.handle(Server.java:303)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:452)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:735)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:636)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:349)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:217)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)

This accounts also for some of the wfsv failures.
Now, the problem became apparent as a result of my [https://jira.codehaus.org/browse/GEOS-1893" title="Required param missing in GetFeature, funny error back" class="issue-link" data-issue-key="GEOS-1893"><del>GEOS-1893</del> fix, but it's actually a problem in the Dispatcher.
When the request comes in, strict=true forces KVP parsing, which bombs out because the kvp reader for the GetFeature
operation is found but of course the kvp part of the request is not complete.

The kvp parsing triggers also because we're looking for the kvp parser associated to GetFeatureType.class, but the
request class was determined observing the xml post part of the request. Maybe we should keep a flag indicating
how we recognized the request, and trigger mixed get/post parsing only if the request was recognized using the
KVP part? This should cover the mixed get/post requests in WMS, ... right? Damn, cannot find an example of that, but
afair the use case was to provide just the SLD as post and the rest with the GET kvp params?

Anyways, marking as blocker for the next release, since it's a regression