Hi, I didn't mean to imply any of this discussion is invalid, or even boring: it's both valid and interesting. The points I wanted to make are two:
- We Tomcat developers are required to adhere to the Servlet Spec. In some cases we can provide functionality beyond the Spec, at our discretion, but on core things we want to stick to the Spec as rigidly as possible. This sometimes puts developers or deployers at a bit of an inconvenience, like in your case. - Every release of Tomcat is validated rigorously against the Servlet and JSP TCKs. There are explicit test cases that cover request parameter parsing and handling. No release of Tomcat is pronounced stable unless it passes the TCK tests completely, i.e. no failures. So that's why I said any ambiguities in the Spec or areas where you think the Spec could be improved should be addressed to the Expert Group. They have contact info on the JSR154 home page. I didn't say that to get you off our backs: I said that because they are interested in hearing from you, it's their job. In addition, the Spec is not a dead/inactive thing: it's constantly evolving, mostly in response to community demands. Some areas of the Servlet Spec, as you noted, are subject to external standards. For example, there are RFCs that define Cookie formats, the Servlet Spec abides by these and therefore its implementations like Tomcat must be compliant. But there are many things in the Servlet Spec that are not specified by another standard, so for them the Spec is the authority. One other minor note: I see several references in this thread to the Servlet Spec v2.3. As you know, v2.4 is the current version, and the one Tomcat 5.x implements. Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: Dave Dribin [mailto:[EMAIL PROTECTED] >Sent: Thursday, September 23, 2004 5:05 PM >To: Tomcat Users List >Subject: Re: getParameter() should be case insensitive? > >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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
