At 1:20 AM -0800 1/21/07, Chris Hostetter wrote: >: We need code to do that anyway since getParameterMap() doesn't support >: getting params from the URL if it's a POST (I believe I tried this in >: the past and it didn't work). > >Uh ... i'm pretty sure you are mistaken ... yep, i've just checked and you >are *definitely* mistaken. > >getParameterMap will in fact pull out params from both the URL and the >body if it's a POST -- but only if you have not allready accessed either >getReader or getInputStream -- this was at the heart of my cumbersome >preProcess/process API that we all agree now was way too complicated.
The rules are very explicitly laid out in the Servlet 2.4 specification: ----- SRV.4.1.1 When Parameters Are Available The following are the conditions that must be met before post form data will be populated to the parameter set: 1. The request is an HTTP or HTTPS request. 2. The HTTP method is POST. 3. The content type is application/x-www-form-urlencoded. 4. The servlet has made an initial call of any of the getParameter family of methods on the request object. If the conditions are not met and the post form data is not included in the parameter set, the post data must still be available to the servlet via the request object's input stream. If the conditions are met, post form data will no longer be available for reading directly from the request object's input stream. ----- As Hoss notes a POST request can still have GET-style parameters in the URL query string, and getParameterMap will return both sets intermixed for a POST meeting the above conditions. And calling getParameterMap won't impede the ability to subsequently read the input stream if the conditions are not met: "the post data must still be available to the servlet". So it's theoretically valid to simply call getParameterMap and then blindly call getInputStream (possibly catching an Exception), or else use the results of getParameterMap to decide whether and how to process the input stream. The bugaboo is if the POST data is NOT in fact application/x-www-form-urlencoded but the user agent says it is -- as both of you have indicated can be the case when using curl. Could that be why Yonik thought POST params was broken? - J.J.
