-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Sean,
On 2/20/15 5:00 PM, Sean Dawson wrote: > On Fri, Feb 20, 2015 at 4:41 PM, Konstantin Kolinko > <knst.koli...@gmail.com> wrote: > >> 2015-02-21 0:10 GMT+03:00 Sean Dawson >> <seandawson2...@gmail.com>: >>> We have a GWT app deployed to tomcat (7_59) and fairly often >>> when we >> send a >>> bunch of request quickly we're seeing undefined methods in the >>> logs - and the calls fail, causing issues with our app. We >>> make calls via RestyGwt (latest version) but GwtRequests all >>> show this - both though after a >> number >>> of REST calls in a short period of time. So for example... >>> >>> [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path1 >>> HTTP/1.1" 200 >> 304 >>> [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path2 >>> HTTP/1.1" 200 >> 310 >>> [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path3 >>> HTTP/1.1" 200 >> 307 >>> [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE >>> /path4 HTTP/1.1" 501 304 [ip-addr] - - [20/Feb/2015:15:24:34 >>> -0500] "DELETE /path5 HTTP/1.1" 200 >> 304 >>> [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path6 >>> HTTP/1.1" 200 >> 310 >>> [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path7 >>> HTTP/1.1" 200 >> 307 >>> [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE >>> /path8 HTTP/1.1" 501 304 >>> >>> Similarly... >>> >>> ... .... "undefinedPOST /gwtRequest HTTP/1.1" 501 1136 >>> >>> Very little info online, but did come across this old bug... >>> >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=49779 >>> >>> In fiddler, the headers are identical between the requests that >>> work and those that fail. Resending the failed request >>> completes normally. >>> >>> So far we've only be able to reproduce this when using Internet >>> Explorer (10 & 11) and we've spent a lot of time trying to >>> figure out what's going on - but have been unable. Any >>> pointers/explanations? >>> >>> Thanks! >> >> "undefined" is a JavaScript word. In Java I would expect "null" >> instead of that word. >> >>> In fiddler, the headers are identical between the requests that >>> work and those that fail. >> >> The string in access log is not a header. It is HTTP request >> line. The first line of an HTTP request. >> >> > Ok, but this is in the standard tomcat access logs, using standard > logging, and is in the method name, not URL. Maybe I'm not > understanding what you're saying here. > > >> BTW, a similar issue at stackoverflow (but the "undefined" string >> was added to URL part of request line): >> >> >> http://stackoverflow.com/questions/11017609/undefined-randomly-appended-in-1-of-requested-urls-on-my-website-since-12-jun >> >> Title: “undefined” randomly appended in 1% of requested urls on my >> website since 12 june 2012 >> >> > We did come across it but again our's is in the method, not in the > URL. > > >> >> One of theories there is that some browser addon was >> malfunctioning. >> >> > Ok, this has happened on about 5 people's machines with a couple > different versions of IE - I don't think we have any addons at all > in some cases. > > >> If nothing else helps, it should be easy to implement a Valve >> for Tomcat that will fix the wrong request.getMethod() value >> before passing it to a web application. >> >> > I don't know much about that but we could give it a try - so.... > someone else is changing the method somewhere before it gets to > tomcat? and the Valve will change it back? Fiddler isn't the authority when it comes to what is going across the wire. It's possible that something is happening after Fiddler takes its samples. Are you able to hook-up something like Wireshark or other packet-capturing software to see what actually goes over the wire? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU6On7AAoJEBzwKT+lPKRY8vEQAJiupeJotnZVWXFeL5wbwAfw 5nDiXz1wu6IcY0FNingOx/cgorIxJP1Ti6qNY06gXfEG/sJ+Fk1MNn4bbtxoPv5P nRpMjSC1jloxmMK+Y6RKTt5815yCAiggd/mJONzK6NN+vfG6hg4C0l9GnCnuuMte 9mDUkkqogkn2EGYJQua3JiCoQT+qAJbOA+zxRJJcLHB+GzSQLHT48KYAmJQVRWH2 CRtFXQxPtuE0QVaMCWJQcSKqFuJ2y9ZiP77E2DJfo644/4VP2sDk2rIk3MtJCT3F gfLWbMMFcV27QTXQvH3uYXhdEfrVhTUGxurio95gVD6y0g7F4pMYeJAcvTnYVV8Y C9OhHLJrn4NXJ34D7XIzefTaVc8kcp/oVKe7irLK9IapIIqdX+H0P3uHuFCPFEPg aKSNVJ80jD72/yjUAiULgagjOJ7k4b9WhnsrZJFCRydT5yCcK7w3UrNdIDgQSltp TjfJTfCitCzb6/pXMnT+DE7PyPQyeIviU+7rCs89xBNHAoFyYJ+agJOu6CE/hMhg LT672uLvkt4XD2eLE5yUYOHY7KkIKV6WfYPtyyamnoy9vpCPLTxlH6ZyRg+xt17D zP201nRf4Hyay6x7vi+cB4SZ1f5nUS8eV5hPrDZmLiIksdSqzkZFD/a5/JMsa07C esM43RAOa8/LxmJCiyqz =gMzK -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
