If you want to discuss the servlet spec... please take it to the servlet spec group whereever they may be.
This forum is for Tomcat specific questions. You already know the answer for how Tomcat deals with the getParameter method. >>> [EMAIL PROTECTED] 09/23/04 02:04PM >>> On Sep 23, 2004, at 3:34 PM, Shapira, Yoav wrote: > Hi, > I guess the part where I said we didn't have a choice, we must > implement > the servlet spec as-is, and if you don't like it contact the expert > group, wasn't clear? ;) I hope it is now. Thanks for your input! I guess I was looking for some objective discussion on the possibility of the Servlet API being incorrect, according to the standards its supposed to implement. The Servlet specification ultimately needs to adhere to external standards. For example, HttpRequest.getHeader() is case insensitive because RFC 2616 says HTTP headers are case insensitive. So presumably HttpRequest.getParameter() is case sensitive because *something* says so... I just don't know what. Surprisingly, the servlet spec is quite clear on this issue: getParameter() is not valid for GET requests (which was totally unexpected). Servlet Spec 2.3, Section SRV.4.1: "Path parameters that are part of a GET request (as defined by HTTP1.1) are not exposed by these APIs. They must be parsed from the String values returned by the getRequestURI method or the getPathInfo method." getParameter() is only valid for POST requests of the content type application/x-www-form-urlencoded. So, it sounds like applications cannot count on a servlet container to implement getParameter() for GET requests at all, which is completely unbelievable, IMHO. And strictly speaking, Tomcat should actually not return anything for GET requests. Though, this would conceivable break *tons* of applications. Hrm.... -Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
