2014-04-07 21:28 GMT+04:00 Jess Holle <je...@ptc.com>:
> And looking at the data in Request *before* I invoke getParameter*() in our
> code, I see that parametersParsed is set to "true".
>
> I'm not sure if I should expect this to "true" at this point (entry to my
> first filter) for a GET request with a fairly stock Tomcat 7.0.50/53
> configuration. It doesn't seem like it should be...
>
> Tinkering with the internal state of the Request object, to set
> parametersParsed to false and/or parameterMap to null in the debugger
> doesn't help getParameterMap() succeed, though...
>
> --
> Jess Holle
>
>
> On 4/7/2014 11:52 AM, Jess Holle wrote:
>>
>> P.S. The only way I currently know to reproduce this issue is with a full
>> install of our full commercial product plus optional modules -- and then to
>> load large, sensitive customer data into this product and execute a very
>> specific use case.
>>
>> How this could possibly be related to Spring or /any /specifics of this
>> use is a mystery to me.
>>
>> I understand, however, that the requirements to reproduce this issue throw
>> at least the initial troubleshooting and debugging squarely into my lap,
>> which is why I'm asking for pointers, not filing bugs.
>>
>> A little more version information (in case it is relevant):
>>
>> * Sprint 3.2.2
>> * JDK 7u51
>>
>> --
>> Jess Holle
>>
>> On 4/7/2014 10:21 AM, Jess Holle wrote:
>>>
>>> We're seeing a bizarre failure of getParameterMap() wherein this servlet
>>> API returns an empty map.
>>>
>>> I thought we'd loused this up somehow via our servlet request filters,
>>> but the debugger shows this result on the very first line of our very first
>>> filter -- with the request object being Tomcat's own.
>>>
>>> To make matters worse, this is a GET request with a /very /simple URL.
>>>
>>> The query string is very simple "?ids=41&jsonSupport=true". The value of
>>> "ids" varies, but it's numeric and the cases I'm looking at are 2 to 4
>>> digits in length. The rest of the request URI is short and all ASCII, being
>>> of the form {webAppName}/xxxx/yy.
>>>
>>> This is being reproduced with both 7.0.50 and 7.0.53 -- with mod_jk
>>> 1.2.37 and httpd 2.2.26.
>>>
>>> As with https://issues.apache.org/bugzilla/show_bug.cgi?id=55695, we are
>>> using Spring MVC -- and getting a similar error message. Given the point in
>>> request handling at which we're getting the erroneous result, I don't see
>>> how this is actually related to Spring MVC, but I also don't have any idea
>>> how one could reproduce the issue without Spring MVC or our (large
>>> proprietary) web application.
>>>
>>> Any suggestions for getting to the bottom of this issue would be greatly
>>> appreciated!
>>>
Several quick thoughts....
1. What is the value of
request.getAttribute("org.apache.catalina.parameter_parse_failed")
after you obtain that parameters map?
See Tomcat's o.a.c.filters.FailedRequestFilter for an example.
It will be non-null if there was any trouble when parsing the parameters.
2. What is the value of HttpServletRequest.getQueryString() ?
Is it what you expect?
I think you may also configure AccessLogValve to print it and maybe
also to print the parameters.
3. Put a breakpoint into o.a.c.connector.Request#getParameterMap().
Does it work as expected?
If I understand it correctly, from a quick look the method is not
thread-safe. There should not be concurrent requests to it.
4. Try to set ....RECYCLE_FACADES system property to "true"? (See
sysprops page of configuration reference for the full name of the
property).
E.g. if request object is shared between threads, there will be problems.
5.
>> * Sprint 3.2.2
There are several known (unrelated) issues,
http://www.gopivotal.com/security/
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
