Re: getParameter() should be case insensitive?
Dave You had me worried there, for a moment... 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: I read the specs again, and then I realised that you are getting mixed between path parameters and request parameters - and the bit of the specifications you looked at (and quoted) refers to path parameters, not request parameters. In Hans Bergsten (author of Author of JavaServer Pages, O'Reilly) own words, copied from another forum discussion I just Googled... quote A path parameter and a request parameter are two different things. A path parameter can be inserted at any node in a URL, and is used in the Servlet API to encode the session ID in the URL: /foo/bar;jsessionid=1234567 A request parameter is defined using a query string in the URL: /foo/bar?a=b Both types of parameters can be used in the same URL: /foo/bar;jsessionid=1234567?a=b The Servlet API currently does not provide direct access to path parameters and treats the session ID path parameter in a special way (strips it off and uses it to associate the request with the specified session). If you need to use other path parameters, you must use getRequestURI() and parse the string yourself. The getParameter() method, et. al, returns request parameters. In addition to parameters defined by a query string, these methods also find parameters defined in the body of a POST request. So, the answer to your question is, it's safe to use getParameter() et. al. to access request parameter values for both GET and POST requests in all normal cases. The exception is a POST request that uses a content type other than application/x-www-form-urlencoded, for instance a file upload request (multipart/form-data). /quote There you go - you can sleep easy again :-) Regards Harry Mantheakis London, UK 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]
RE: getParameter() should be case insensitive?
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]
getParameter() should be case insensitive?
Hi all, I need to settle a debate here in the office... HttpServlet.getParamter() is case sensitive, i.e., these are not the same: request.getParameter(name); request.getParameter(Name); This is, however, contrary to other APIs and even the HTML spec (I believe). For example, Apache::Request treats parameter names as case insensitive: http://search.cpan.org/~joesuf/libapreq-1.3/Request/Request.pm and I've been told that both ASP and ASP.NET are case insensitive (don't have access, so can't test myself). The HTML 4.01 specification specifically states that form input names are case insensitive: http://www.w3.org/TR/html401/interact/forms.html#h-17.4 Now, the HTML spec doesn't specify how the browser should create the GET URL, only that the user agent treat them as case insensitive. So, does anyone have a normative reference to support the Tomcat and servlet API stating that the current, case sensitive getParameter() behavior is correct? I've muddled through RFCs and can't seem to find anything to support that. Thanks! -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getParameter() should be case insensitive?
Hi, This is, however, contrary to other APIs and even the HTML spec (I believe). For example, Apache::Request treats parameter names as case insensitive: As you noted, the HTML spec doesn't apply to servlet containers, only user agents. What ASP/ASP.NET do is also irrelevant. The Servlet Spec controls how the Servlet API is designed, and Tomcat implements the Spec (we have no choice in this particular matter). So they're inconsistent, and if that's an issue for you take it up with the Servlet Spec Expert Group. For Servlets, there's no other standards (W3C RFC's, etc.) -- the Servlet Specification is the ultimate authority. Yoav 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]
RE: getParameter() should be case insensitive?
Though it may be true that there are not requirements about case insensitivity in the specification, it would be nice to make the world consistent and all it would take is for the developers to start using String.compareToIngnoreCase() instead of String.compareTo(). I would especially like this in the use of the URL and URI names. Often the end users of our code don't understand why there has to be a difference between /myapp/servlet/myservlet and /MYAPP/SERVLET/MYSERVLET. Robert S. Harper 801.265.8800 ex. 255 -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 2:24 PM To: Tomcat Users List Subject: RE: getParameter() should be case insensitive? Hi, This is, however, contrary to other APIs and even the HTML spec (I believe). For example, Apache::Request treats parameter names as case insensitive: As you noted, the HTML spec doesn't apply to servlet containers, only user agents. What ASP/ASP.NET do is also irrelevant. The Servlet Spec [snip] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getParameter() should be case insensitive?
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. Yoav Shapira Millennium Research Informatics -Original Message- From: Robert Harper [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 4:31 PM To: 'Tomcat Users List' Subject: RE: getParameter() should be case insensitive? Though it may be true that there are not requirements about case insensitivity in the specification, it would be nice to make the world consistent and all it would take is for the developers to start using String.compareToIngnoreCase() instead of String.compareTo(). I would especially like this in the use of the URL and URI names. Often the end users of our code don't understand why there has to be a difference between /myapp/servlet/myservlet and /MYAPP/SERVLET/MYSERVLET. Robert S. Harper 801.265.8800 ex. 255 -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 2:24 PM To: Tomcat Users List Subject: RE: getParameter() should be case insensitive? Hi, This is, however, contrary to other APIs and even the HTML spec (I believe). For example, Apache::Request treats parameter names as case insensitive: As you noted, the HTML spec doesn't apply to servlet containers, only user agents. What ASP/ASP.NET do is also irrelevant. The Servlet Spec [snip] - 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]
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]
Re: getParameter() should be case insensitive?
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]
