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]
