Thanks for the additional suggestions! Will try those on Monday.
On Sat, Feb 21, 2015 at 3:26 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----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 > >
