Re: unified doXXX()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aryeh,
On 3/2/2010 7:12 PM, Aryeh M. Friedman wrote:
Christopher Schultz wrote:
If that string above is your entire POST request body, then it's not
properly formatted. Instead, it should be:
call=8347812459870132405987234985023450987
or whatever. The parameter has to have a name :)
Design decision for two reasons:
Just so you know, your design decision means that POST will /never/ work
using request.getParameter.
1. If we are already decoding the request from hex to plain text
mightiest use getReader()
2. Our app needs to support several frontends (not just the web via a
servlet)
I don't believe either of these issues should present a problem. I would
think you could do the following as a POST request body:
call=[encode(call=36418724r58734523874)]
...and then just do request.getParameter(call) whether it's GET or POST.
Just for reference here is the refactored servlet with any trade secret
code removed (all the tomcat--servlet logic is kept)
[snip]
try {
call=StringUtil.hexToString(
readRequest(request)).substring(5);
} catch(IOException e) {
write out error in custom format
}
Good luck with that code.
private String readRequest(HttpServletRequest request)
throws IOException
{
if(request.getMethod().equals(GET))
return request.getQueryString();
Oh, so you were using the whole query string and not just the value of
one parameter? Wow, you've really changed-up the whole thing, eh?
String out=;
Reader reader=request.getReader();
// reading all the content in one read causes problems
sometimes so we read it char by char
This comment is an indication of something wrong. :(
for(int i=0;irequest.getContentLength();i++)
out+=(char) reader.read();
Nice.
private static final long serialVersionUID=0L;
This class isn't serializable. It's odd to set a serialVersionUID for a
class that isn't serializable. Also, it's weird to set its value to
zero. shrug
Hey, if what you've got here works, then who am I to interfere?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuP39QACgkQ9CaO5/Lv0PBOiQCffq5J3k23zHTrSAnwrxhAVP6N
bwMAoJT3NIl3+ALbqR4yfFdGv6E5Nk6J
=jClC
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 1:51 AM, Aryeh M. Friedman wrote: Yes we are and thats why I probably mistook the effect of it doing that as a side effect instead of a designed in feature... now that being said we have used that content day since the first few lines of our code was written and until this post (about 2 years) the servlet getting getParameter via GET *AND* POST was not an issue... but for some reason a new client side request format (which there is no easy way around not using) messed it up. Ok, so what's next? Sometimes you are getting a null when you expect data, right? Well, are you only getting null when the request is a GET? POST? Or is it something else? If you wanted to get cute, you could implement this one-parameter-to-rule-them-all strategy as a Filter which wraps the request and provides a simpler getParameter interface to your webapps. Instead of this: String everything = getParameter(everything); String specific = parseSpecific(everything); You could have your webapp code simply do this: String specific = request.getParameter(specific); ... then the request wrapper does all the work to gather the parameter information from the right place, decode it, and return the data to the caller. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuNU4QACgkQ9CaO5/Lv0PDchQCgrQnhx7BOyqAXLBkBxPw0UHz8 Ak8AoJRNRyGI22Be11LjM4mS7bkRSmOt =9AtG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 1:51 AM, Aryeh M. Friedman wrote: Yes we are and thats why I probably mistook the effect of it doing that as a side effect instead of a designed in feature... now that being said we have used that content day since the first few lines of our code was written and until this post (about 2 years) the servlet getting getParameter via GET *AND* POST was not an issue... but for some reason a new client side request format (which there is no easy way around not using) messed it up. Ok, so what's next? Sometimes you are getting a null when you expect data, right? Well, are you only getting null when the request is a GET? POST? Or is it something else? It gets null's on POST's only but only from the new input format (there are parts of the app that still use the old format and they work fine) If you wanted to get cute, you could implement this one-parameter-to-rule-them-all strategy as a Filter which wraps the I will consider that as a future refactoring - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 2:20 PM, Aryeh M. Friedman wrote: It gets null's on POST's only but only from the new input format (there are parts of the app that still use the old format and they work fine) Is this a new client, or just a new data format? Mark's suggestion that you may be using POST without the proper Content-Type would result in getting null for this parameter (because Tomcat will not parse it for you). If this is the case, you should either fix the new client to use the proper Content-Type, or fall-back to reading and parsing the request body manually when these requirements are not met. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuNeKYACgkQ9CaO5/Lv0PD9hQCguupor2zsCikSUCPUNQhnrDfK TIQAn1Wli/dVvtXKgBVYIko2pHSBEYut =O0Co -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 2:20 PM, Aryeh M. Friedman wrote: It gets null's on POST's only but only from the new input format (there are parts of the app that still use the old format and they work fine) Is this a new client, or just a new data format? Mark's suggestion that you may be using POST without the proper Content-Type would result in getting null for this parameter (because Tomcat will not parse it for you). If this is the case, you should either fix the new client to use the proper Content-Type, or fall-back to reading and parsing the request body manually when these requirements are not met. New format same frontend client code which does use the proper content type. (the content type is defined at a lower level then the format and that code has not changed [using firebug on firefox confirms that fact]) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 3:48 PM, Aryeh M. Friedman wrote: Christopher Schultz wrote: Is this a new client, or just a new data format? Mark's suggestion that you may be using POST without the proper Content-Type would result in getting null for this parameter (because Tomcat will not parse it for you). If this is the case, you should either fix the new client to use the proper Content-Type, or fall-back to reading and parsing the request body manually when these requirements are not met. New format same frontend client code which does use the proper content type. (the content type is defined at a lower level then the format and that code has not changed [using firebug on firefox confirms that fact]) Hmm. So, POST + application/x-www-form-urlencoded yields a null parameter with your new payload? I know this sounds silly, but we're getting down to the grasping-at-straws level, here, so bear with me: have you checked to see that your request body is actually in the correct format (that is, urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might give up if the request body is not parsable. Have you tried calling request.getInputStream and dumping the request body when the parameter is null? That might give you some indication of what's happening. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuNe+AACgkQ9CaO5/Lv0PArcwCdHf9ddwqWTKkoYb0jA9BHDs+/ LUoAnj6gNWY5mdPoCAxmgfKceWxSBy6r =wn5q -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 3:48 PM, Aryeh M. Friedman wrote: Christopher Schultz wrote: Is this a new client, or just a new data format? Mark's suggestion that you may be using POST without the proper Content-Type would result in getting null for this parameter (because Tomcat will not parse it for you). If this is the case, you should either fix the new client to use the proper Content-Type, or fall-back to reading and parsing the request body manually when these requirements are not met. New format same frontend client code which does use the proper content type. (the content type is defined at a lower level then the format and that code has not changed [using firebug on firefox confirms that fact]) Hmm. So, POST + application/x-www-form-urlencoded yields a null parameter with your new payload? I know this sounds silly, but we're getting down to the grasping-at-straws level, here, so bear with me: have you checked to see that your request body is actually in the correct format (that is, urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might give up if the request body is not parsable. Have you tried calling request.getInputStream and dumping the request body when the parameter is null? That might give you some indication of what's happening. The client does url encode in addition to translating any chars that are used either by tomcat and/or or app to decode the reaquest (namely = is translated to ^, comma to #, right/left parens to @ and $ respectivally) then I use javascripts escape(string) method to url encode it the app by default uses post but if I cut and paste the resulting payload into a GET and pass it to the app it works fine (i.e. the app uses POST but I do manual testing with GET) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Aryeh M. Friedman wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 3:48 PM, Aryeh M. Friedman wrote: Christopher Schultz wrote: Is this a new client, or just a new data format? Mark's suggestion that you may be using POST without the proper Content-Type would result in getting null for this parameter (because Tomcat will not parse it for you). If this is the case, you should either fix the new client to use the proper Content-Type, or fall-back to reading and parsing the request body manually when these requirements are not met. New format same frontend client code which does use the proper content type. (the content type is defined at a lower level then the format and that code has not changed [using firebug on firefox confirms that fact]) Hmm. So, POST + application/x-www-form-urlencoded yields a null parameter with your new payload? I know this sounds silly, but we're getting down to the grasping-at-straws level, here, so bear with me: have you checked to see that your request body is actually in the correct format (that is, urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might give up if the request body is not parsable. Have you tried calling request.getInputStream and dumping the request body when the parameter is null? That might give you some indication of what's happening. The client does url encode in addition to translating any chars that are used either by tomcat and/or or app to decode the reaquest (namely = is translated to ^, comma to #, right/left parens to @ and $ respectivally) then I use javascripts escape(string) method to url encode it the app by default uses post but if I cut and paste the resulting payload into a GET and pass it to the app it works fine (i.e. the app uses POST but I do manual testing with GET) opps forgot to mention the manual test works for both the new and old format but the automated method only works for the old format (both formats use the one param to rule them all strategy) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 3:48 PM, Aryeh M. Friedman wrote: Christopher Schultz wrote: Is this a new client, or just a new data format? Mark's suggestion that you may be using POST without the proper Content-Type would result in getting null for this parameter (because Tomcat will not parse it for you). If this is the case, you should either fix the new client to use the proper Content-Type, or fall-back to reading and parsing the request body manually when these requirements are not met. New format same frontend client code which does use the proper content type. (the content type is defined at a lower level then the format and that code has not changed [using firebug on firefox confirms that fact]) Hmm. So, POST + application/x-www-form-urlencoded yields a null parameter with your new payload? I know this sounds silly, but we're getting down to the grasping-at-straws level, here, so bear with me: have you checked to see that your request body is actually in the correct format (that is, urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might give up if the request body is not parsable. Have you tried calling request.getInputStream and dumping the request body when the parameter is null? That might give you some indication of what's happening. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuNe+AACgkQ9CaO5/Lv0PArcwCdHf9ddwqWTKkoYb0jA9BHDs+/ LUoAnj6gNWY5mdPoCAxmgfKceWxSBy6r =wn5q -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Also forgot to mention I already refactored the servlet to use pure hex encoding (namely we convert the entire request into a hex string so for example a old format message of call=default.Session.getSession() gets translated into 63616c6c3d64656661756c742e53657373696f6e2e67657453657373696f6e2829 which the servlet then decodes and then does it own parsing (in both formats the call param [our does it all param] has roughly the format above [i.e. a psedo method call like format])... by new format I only mean we got a query string that exceeds 1k for the first time - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 4:05 PM, Aryeh M. Friedman wrote: Aryeh M. Friedman wrote: Aryeh M. Friedman wrote: Christopher Schultz wrote: I know this sounds silly, but we're getting down to the grasping-at-straws level, here, so bear with me: have you checked to see that your request body is actually in the correct format (that is, urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might give up if the request body is not parsable. Have you tried calling request.getInputStream and dumping the request body when the parameter is null? That might give you some indication of what's happening. The client does url encode in addition to translating any chars that are used either by tomcat and/or or app to decode the reaquest (namely = is translated to ^, comma to #, right/left parens to @ and $ respectivally) then I use javascripts escape(string) method to url encode it the app by default uses post but if I cut and paste the resulting payload into a GET and pass it to the app it works fine (i.e. the app uses POST but I do manual testing with GET) Wait, what? Why all that extra encoding? Well, I guess you know what you're doing. opps forgot to mention the manual test works for both the new and old format but the automated method only works for the old format (both formats use the one param to rule them all strategy) Obviously, something is different. Check everything between your manual and automated tests and see what is different. Maybe it's a trailing newline. Maybe it's a Content-Length header. Whatever it is, apparently, it's significant. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuNl08ACgkQ9CaO5/Lv0PDBlgCgsgeTljstZhft+VK0ail2xfPC hWsAnje2YQ7OMKt3u6bjfBT6z5zSXTs8 =gh1k -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 4:12 PM, Aryeh M. Friedman wrote: Also forgot to mention I already refactored the servlet to use pure hex encoding (namely we convert the entire request into a hex string so for example a old format message of call=default.Session.getSession() gets translated into 63616c6c3d64656661756c742e53657373696f6e2e67657453657373696f6e2829 If that string above is your entire POST request body, then it's not properly formatted. Instead, it should be: call=8347812459870132405987234985023450987 or whatever. The parameter has to have a name :) by new format I only mean we got a query string that exceeds 1k for the first time You'll likely to have to switch to POST for query strings that exceed 1k. Good motivation to get this working! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuNl9sACgkQ9CaO5/Lv0PA/TwCfTYmTmuLNR2ZMyQNd+vKKNwm+ YcMAoIWqULxZ9s2v1mZ63xAZFjhO+/CR =S8tm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
On 02/03/2010 21:04, Aryeh M. Friedman wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 3:48 PM, Aryeh M. Friedman wrote: Christopher Schultz wrote: Is this a new client, or just a new data format? Mark's suggestion that you may be using POST without the proper Content-Type would result in getting null for this parameter (because Tomcat will not parse it for you). If this is the case, you should either fix the new client to use the proper Content-Type, or fall-back to reading and parsing the request body manually when these requirements are not met. New format same frontend client code which does use the proper content type. (the content type is defined at a lower level then the format and that code has not changed [using firebug on firefox confirms that fact]) Hmm. So, POST + application/x-www-form-urlencoded yields a null parameter with your new payload? I know this sounds silly, but we're getting down to the grasping-at-straws level, here, so bear with me: have you checked to see that your request body is actually in the correct format (that is, urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might give up if the request body is not parsable. Have you tried calling request.getInputStream and dumping the request body when the parameter is null? That might give you some indication of what's happening. The client does url encode in addition to translating any chars that are used either by tomcat and/or or app to decode the reaquest (namely = is translated to ^, comma to #, right/left parens to @ and $ respectivally) then I use javascripts escape(string) method to url encode it the app by default uses post but if I cut and paste the resulting payload into a GET and pass it to the app it works fine (i.e. the app uses POST but I do manual testing with GET) Small aside: are javascript encodeURI() or encodeURIComponent() not suitable for some reason? (I ask out of curiosity) p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 4:05 PM, Aryeh M. Friedman wrote: Aryeh M. Friedman wrote: Aryeh M. Friedman wrote: Christopher Schultz wrote: I know this sounds silly, but we're getting down to the grasping-at-straws level, here, so bear with me: have you checked to see that your request body is actually in the correct format (that is, urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might give up if the request body is not parsable. Have you tried calling request.getInputStream and dumping the request body when the parameter is null? That might give you some indication of what's happening. The client does url encode in addition to translating any chars that are used either by tomcat and/or or app to decode the reaquest (namely = is translated to ^, comma to #, right/left parens to @ and $ respectivally) then I use javascripts escape(string) method to url encode it the app by default uses post but if I cut and paste the resulting payload into a GET and pass it to the app it works fine (i.e. the app uses POST but I do manual testing with GET) Wait, what? Why all that extra encoding? Well, I guess you know what you're doing. opps forgot to mention the manual test works for both the new and old format but the automated method only works for the old format (both formats use the one param to rule them all strategy) Obviously, something is different. Check everything between your manual and automated tests and see what is different. Maybe it's a trailing newline. Maybe it's a Content-Length header. Whatever it is, apparently, it's significant. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuNl08ACgkQ9CaO5/Lv0PDBlgCgsgeTljstZhft+VK0ail2xfPC hWsAnje2YQ7OMKt3u6bjfBT6z5zSXTs8 =gh1k -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org The above issues is why we switched to the hex encoding scheme - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aryeh,
On 3/2/2010 4:12 PM, Aryeh M. Friedman wrote:
Also forgot to mention I already refactored the servlet to use pure
hex encoding (namely we convert the entire request into a hex string
so for example a old format message of
call=default.Session.getSession() gets translated into
63616c6c3d64656661756c742e53657373696f6e2e67657453657373696f6e2829
If that string above is your entire POST request body, then it's not
properly formatted. Instead, it should be:
call=8347812459870132405987234985023450987
or whatever. The parameter has to have a name :)
Design decision for two reasons:
1. If we are already decoding the request from hex to plain text
mightiest use getReader()
2. Our app needs to support several frontends (not just the web via a
servlet)
Just for reference here is the refactored servlet with any trade secret
code removed (all the tomcat--servlet logic is kept)
// src/backend/servlet/Servlet.java
package backend.servlet;
import java.io.IOException;
import java.io.PrintWriter;
import java.io.Reader;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import backend.util.StringUtil; // hex encoding/decoding
public class Servlet extends HttpServlet
{
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)
throws IOException
{
// not possible to do custom error reporting yet
because we have no writer to write to
PrintWriter pw=new PrintWriter(response.getWriter());
String call=null;
try {
call=StringUtil.hexToString(
readRequest(request)).substring(5);
} catch(IOException e) {
write out error in custom format
}
code to do something with the request
}
private String readRequest(HttpServletRequest request)
throws IOException
{
if(request.getMethod().equals(GET))
return request.getQueryString();
String out=;
Reader reader=request.getReader();
// reading all the content in one read causes problems
sometimes so we read it char by char
for(int i=0;irequest.getContentLength();i++)
out+=(char) reader.read();
return out;
}
private static final long serialVersionUID=0L;
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
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
Re: unified doXXX()
On 01/03/2010 08:01, Aryeh M. Friedman wrote: Pid wrote: 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? Take a look at SRV.3.1 in the servlet spec. Are you sure you are using application/x-www-form-urlencoded with your POST? If you use that content type, Tomcat will merge parameters in the POST body and the query string. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Mark Thomas wrote: On 01/03/2010 08:01, Aryeh M. Friedman wrote: Pid wrote: 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? Take a look at SRV.3.1 in the servlet spec. Are you sure you are using application/x-www-form-urlencoded with your POST? If you use that content type, Tomcat will merge parameters in the POST body and the query string. Yes we are and thats why I probably mistook the effect of it doing that as a side effect instead of a designed in feature... now that being said we have used that content day since the first few lines of our code was written and until this post (about 2 years) the servlet getting getParameter via GET *AND* POST was not an issue... but for some reason a new client side request format (which there is no easy way around not using) messed it up. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
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?
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?
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?
Is request.getInputStream() not suitable?
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.
p
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
unified doXXX()
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:
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
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()).
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
