> consider the example you've got on your test.html page: "POST - with query
> string" ... that doesn't obey the typical semantics of a POST with a query
> string ... if you used the methods on HttpServletRequest to get the params
> it would give you all the params it found both in the query strings *and*
> in the post body.
Blech. I was wondering about that. Sounds like bad form, but perhaps could be
supported via something like
/solr/foo?postbody=args
In my opinion, I don't think we need to worry about it for the
*default* handler. That is not a very difficult constraint and, there
is no one out there expecting to be able to post parameters in the URL
and the body. I'm not sure it is worth complicating anything if this
is the only thing we are trying to avoid.
I think the *default* should handle all the cases mentioned without
the client worrying about different URLs for the various methods.
The next question is which (if any) of the explicit parsers you think
are worth including in web.xml?
http://${host}/${context}/${path/from/config} (default)
http://${host}/${context}/params/${path/from/config} (used
getParameterMap() to fill args)
http://${host}/${context}/multipart/${path/from/config} (force
multipart request)
http://${host}/${context}/stream/${path/from/config} (params from URL,
body as stream)
