Pid wrote:
On 28/02/2010 02:00, Aryeh M. Friedman wrote:
I am refactoring a servlet we have used successfully for several years
now to accommodate input that does not amen itself to
HttpServletRequest.getParameter()... The only way it seems to be to
handle our particular input (the nature/format of the input is covered
by an NDA so I can not discuss it in any detail) read the raw
request.... in the old servlet HttpServletRequest.getParameter() had a
nice side effect that we where able to do something like this:
I don't understand, can you explain what you mean by a side effect?
See below for details but it appears sun's general servlet api model is
designed to treat each request method differently and getParameter (at
least how I am using it) is a short-circuit of this model.
public void doGet(HttpServletRequest request,HttpServletResponse
response)
throws IOException
{
handleRequest(request,response);
}
public void doPost(HttpServletRequest request,HttpServletResponse
response)
throws IOException
{
handleRequest(request,response);
}
private void handleRequest(HttpServletRequest
request,HttpServletResponse response)
{
String input=Request.getParameter("foo"); // we are only interested in
this one param
"Request" or "request" - is this a typo?
thats what I get for writting sample code for a post only and not
actually compiling it ;-)
process input
}
I want to preserve the single handler design but since getParameter
barfs on our new input format and there is no unified raw input reader
the only thing I can think of is make it so doGet and doPost use
request.getQueryString() and request.getReader() respectivally... is
there an easier way? (namely I want to keep doXXX as pure wrappers with
nothing but a dispatch to handleRequest()).
Why does request.getParameter() not work, or is that a secret?
I am not actually sure because the input is properly URL encoded and
works if sent as a GET but fails (getParameter returns null) if done as
a POST (note every other input sent to this servlet in the past did work
with both GET and POST).... the reason for only caring about one
parameter for all input is a trade secret though.... that being said for
other reasons beyond (that are also trade secrets) the failed
getParameter call we decided to rewrite the servlet so it's entire
payload data is a hex encoded string and thus the need for reading the
raw request instead of using getParameter..... I suspect it is because
we had some funky character encoding (UTF-8 but some characters could be
parsed in more then one way with the context not giving enough clues to
which one was correct) [this was why we switched to hex encoding]
Is request.getInputStream() not suitable?
I thought thats what I was asking ;-).... namely getReader() and
getInputStream() only work if it was a POST (if GET we need to use
getQueryString())
As far as I can see, there's absolutely no reason that handleRequest
won't continue to work, as long as the code inside actually does work.
I thought so also until I traced the bug to the very first line of
handleRequest when it used getParameter (i.e. disagreement on output of
the call depending on request method)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
