You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by PAROLINI Antonio <An...@hcuge.ch> on 2010/03/04 16:58:00 UTC
HttpServletRequest.getParameter() inside a valve
Hello,
We are using a custom valve that scan the request parameters (POST AND GET) . If it find a parameter called "secuId" with a valide value , it set the session principals ( a kind of SSO).When this work most of the times, we have somes cases where calling the HttpServletRequest .getParameter() method within a valve has an impact to the called servlet.
Those cases are a "java.io.IOException: Connection reset by peer: Amount read didn't match content-length " for the WebObject servlet, and a EOFException in the invoker servlet in Jboss).
After some digging, I've found that calling HttpServletRequest .getParameter() does impact the request inputstream. See Craig R. McClanahan reply in this thread: http://markmail.org/message/xstjwbgz5r2ko2oe#query:+page:1+mid:xstjwbgz5r2ko2oe+state:results
So if I cannot use HttpServletRequest .getParameter() in my valve, what other option do i have ?
I've see that there is a request.getCoyoteRequest().getParameter() methode in the low level Tomcat API. Is this an option ?
Thanks in advance for your help,
Antonio
Re: HttpServletRequest.getParameter() inside a valve
Posted by Rainer Frey <ra...@inxmail.de>.
On Thursday 04 March 2010 17:41:17 Christopher Schultz wrote:
> It does: calling request.getParameter will consume the request body if
> the following are true:
>
> 1. The protocol is HTTP or HTTPS
> 2. The method is POST
> 3. The Content-Type is application/x-www-form-urlencoded
> [4. A call to request.getParameter*, which you're already doing]
>
> > Those cases are a "java.io.IOException: Connection reset by peer:
> > Amount read didn't match content-length " for the WebObject servlet,
> > and a EOFException in the invoker servlet in Jboss).
>
> That seems fairly straightforward: the client is sending a
> Content-Length that doesn't match the amount of data sent: too few bytes
> or too many. Can you post the whole stack trace?
Could this be because the input stream of the body is already consumed and the
servlet can't read <Content-Length> number of bytes anymore, even when the
Content-Length header was originally correct?
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: HttpServletRequest.getParameter() inside a valve
Posted by PAROLINI Antonio <An...@hcuge.ch>.
Hey,
Thanks for your analyse.
I guess the only way out of this is to prevent the use of getparameter() in case of a HTTP post. This may be ok for us, as our secuId is sent using the querystring, thus HTTP GET.
I've seen a place where request.getParameter() is used thus: in FormAuthenticator. But after son digging, I've seen that in that case a new request object is build from scratch by the valve and resent to the target servlet.
-antonio
>> Those cases are a "java.io.IOException: Connection reset by peer:
>> Amount read didn't match content-length " for the WebObject servlet,
>> and a EOFException in the invoker servlet in Jboss).
>
>That seems fairly straightforward: the client is sending a
>Content-Length that doesn't match the amount of data sent: too few bytes
>or too many. Can you post the whole stack trace?
Here is the Webobject servlet stacktrace:
java.io.IOException: Connection reset by peer: Amount read didn't match content-length
at com.webobjects.appserver._private.WONoCopyPushbackInputStream.read(WONoCopyPushbackInputStream.java:175)
at com.webobjects.appserver._private.WOInputStreamData._extractBytesFromInputStream(WOInputStreamData.java:105)
at com.webobjects.appserver._private.WOInputStreamData.bytesNoCopy(WOInputStreamData.java:137)
at com.webobjects.foundation.NSData._bytesNoCopy(NSData.java:502)
at com.webobjects.appserver.WOMessage.contentString(WOMessage.java:651)
at Application.dispatchRequest(Unknown Source)
at com.webobjects.jspservlet._WOApplicationWrapper.servletDispatchRequest(_WOApplicationWrapper.java:118)
at com.webobjects.jspservlet.WOServletAdaptor._handleRequest(WOServletAdaptor.java:581)
at com.webobjects.jspservlet.WOServletAdaptor.doPost(WOServletAdaptor.java:548)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.borland.pso.security.web.SecurityServletFilter.doFilter(SecurityServletFilter.java:41)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at hug.jade.security.tomcat.valve.HugSSOValve.invoke(HugSSOValve.java:114)
Re: HttpServletRequest.getParameter() inside a valve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Antonio,
On 3/4/2010 10:58 AM, PAROLINI Antonio wrote:
> We are using a custom valve that scan the request parameters (POST
> AND GET) . If it find a parameter called "secuId" with a valide value
> , it set the session principals ( a kind of SSO).When this work most
> of the times, we have somes cases where calling the
> HttpServletRequest .getParameter() method within a valve has an
> impact to the called servlet.
It does: calling request.getParameter will consume the request body if
the following are true:
1. The protocol is HTTP or HTTPS
2. The method is POST
3. The Content-Type is application/x-www-form-urlencoded
[4. A call to request.getParameter*, which you're already doing]
> Those cases are a "java.io.IOException: Connection reset by peer:
> Amount read didn't match content-length " for the WebObject servlet,
> and a EOFException in the invoker servlet in Jboss).
That seems fairly straightforward: the client is sending a
Content-Length that doesn't match the amount of data sent: too few bytes
or too many. Can you post the whole stack trace?
> So if I cannot use HttpServletRequest .getParameter() in my valve,
> what other option do i have?
Well, if the Content-Length is wrong, you're going to have problems no
matter what. If request.getParameter* fails, I don't think that any
other APIs are going to help you...
> I've see that there is a request.getCoyoteRequest().getParameter()
> methode in the low level Tomcat API. Is this an option ?
I suspect you'll get the same exception from this level of code, too
(I'll even bet that method one calls the other).
If you must, I suppose you could read the request body yourself and
simply ignore the Content-Length mismatch.
Honestly, I would try to figure out why the Content-Type isn't matching
the request body length: this is likely to be a problem with whatever
client you are using. It's possible that it's an encoding mismatch.
Content-Length is supposed to mean number of octets, but it's possible
that your client is reporting the number of characters being sent, which
would probably be less than the number of bytes (though you get an
EOFException, so I'm guessing that the Content-Length is /larger/ than
the body you receive).
Strange.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuP4q0ACgkQ9CaO5/Lv0PBrFwCgg9b2UUemCnMhpncsq3y17UZs
H7EAn0YzqpXr907l4rzTXMV3A3SLpm+b
=eddn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org