Jerry, >From your description, it sounds as if there is something about those requests that either isn't quite right or triggers an edge vase bug in Tomcat's request parsing.
I'm happy to provide some pointers to help you debug this. I'll use 9.0.x links since I assume you prefer to debug this locally. Your starting point for debugging should probably be this class: Parameter parsing is lazy. It doesn't kick in until the application requests a parametyer On 08/12/2019 05:08, Jerry Malcolm wrote: > I have ajax code that sends requests to TC in a REST-style process. I > send the parms url-encoded in the body. This has worked untouched > literally for years. I have some new data objects in my db that "should > be" sending the same type of requests through the same javascript > routines. But for some inexplicable reason, the HttpServletRequest > object is randomly deciding to not process the parms. When I try to > enumerate the parms, I get none. Any parm I request comes back not > found. I added some code to read the body myself (request.getReader(), > etc). When the parms are available as it normally works, the reader is > empty, which is what I would expect since it's been read by the request > obj. But when the request object tells me I have no parms, I can read > the entire url-encoded parm string from the reader, which if I > understand things, means the request object never tried to read the > stream, unless it somehow restores the stream after a read (??). But > the important point I determined is that the parms are indeed present in > the body... just not processed. > > I know this has to be something I'm doing wrong. It only occurs on one > or two new 'product items' on my web app. But it is pretty consistent > on those. I'll refresh 4 or 5 times, and the next time I get the > no-parms situation. I hit refresh again, and it works again. I've > analyzed all the parms and parm values to see if anything strange sticks > out. Nothing looks out of the ordinary. It's a pretty large parm set > (~158 parms). But I don't think that's anywhere near the largest set > I've sent over the years. I've dumped all of the headers for both > success and fail. No differences. The fail still shows the correct > content type and correct content length. Just no parms. I also checked > the logs to see if any exceptions are being thrown. Nothing. And all > of my code executes as normal until it can't find necessary parms and > then it spirals.... Hard drive has tons of space. And this doesn't > sound like a heap problem since it fails consistently on 2 out of 200+ > data objects and works fine on all of the other objects. Those two > objects should only differ from the others in > name/description/price/etc. Obviously, there's something else > different. I just can't figure it out. > > My production env is TC 8.5.xx on AWS Linux. Just to test, I fired up > my Windows laptop TC 9.x and got the exact same symptoms. > > I'm not expecting anyone to solve my problem off the top of their head > (but I won't refuse that if someone really knows what's happening....). > What I really need is just a general overview of how the request object > works regarding url-encoded body parameters (and the impl class TC > uses). Is there simply some code in the impl that checks for > application/x-www-form-urlencoded and reads the buffer, parses the > parms, and stores them in a hash? Where does that occur in the > lifecycle of the request object? If I can just find the code that does > this function in the source, perhaps I can figure out what might make it > randomly decide to ignore this specific set of parms. Or maybe I can > fire everything up in an Eclipse environment and do some debugging. But > a java source file name for the request object impl class and a bit of > functional understanding will really help me along the way. > > Thx > > > > --------------------------------------------------------------------- > 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
