tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aryeh M. Friedman" <>
Subject Re: unified doXXX()
Date Mon, 01 Mar 2010 08:01:16 GMT
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 
> 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:
For additional commands, e-mail:

View raw message