We did try adding PUT to parseBodyMethods but didn't not change the issue.
On Mon, Dec 22, 2014 at 11:24 AM, Sean Dawson <seandawson2...@gmail.com> wrote: > > I don't think so. But perhaps that's the new/current thinking and > something in the latest tomcat/libraries is enforcing that? > > I'll double-check/look-it-up. > > In any case, people do it - and it was working before. > > > On Mon, Dec 22, 2014 at 11:12 AM, David kerber <dcker...@verizon.net> > wrote: > >> On 12/22/2014 11:05 AM, Sean Dawson wrote: >> >>> Hi Konstantin, >>> >>> Thanks for your reply. What details do you need of our config? Do you >>> want >>> the full files? Essentially it's a pretty straightforward install - >>> extract tomcat, remove all the webapps, put our war somewhere, use >>> Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that >>> makes >>> some rpc calls and some REST calls to a different process (which could be >>> on a different server) - everything seems to work up until the point of >>> making this one REST PUT call with some data that's supposed to return >>> some >>> >> >> I don't use REST, so I may be off base here, but is a REST PUT like an >> HTTP PUT in that it's not expected to get any return data? In HTTP, you >> normally use either a POST or a GET if you want a response back. >> >> >> >> data. It's possible that it might have to do with json serialization or >>> dto's - because it's the first call that uses them in the request and >>> response. Exact same config with _42 works fine. Did not see anything >>> in >>> docs/etc that would affect us (but could have missed something). >>> >>> This happens with everything locally on Windows, and remotely on Amazon >>> Linux cloud servers. The request is made, and the status is 200 - but >>> fiddler shows no response data - and the app does not continue at that >>> point (it should do an onSuccess, but it doesn't even do an onFailure). >>> >>> It happens ALL the time with the latest tomcat - never with the older. I >>> can't seem to get any more data about what's going on when it happens. >>> Most things just fail silently - it was only when I started changing up >>> all >>> the configurations (browser-clients/etc) that I got the other messages >>> mentioned. >>> >>> >>> >>> On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko < >>> knst.koli...@gmail.com> >>> wrote: >>> >>> 2014-12-19 20:49 GMT+03:00 Sean Dawson <seandawson2...@gmail.com>: >>>> >>>>> Hello, >>>>> >>>>> We had a gwt app deployed and working with tomcat 7_42 and tried it >>>>> recently in several configurations (Windows/Linux) with the latest >>>>> update >>>>> of 7 and it fails during a RestyGwt/RestEasy call to the server. >>>>> Previous >>>>> calls succeed but this particular one appears to get an http code of >>>>> 200 >>>>> but doesn't return any data (but it should) - and so the app never >>>>> proceeds. There's no message, exception, etc - so the app just sits >>>>> >>>> there. >>>> >>>>> >>>>> In running this on several clients (Firefox, Chrome, RestClient for FF, >>>>> etc), I *have* received a couple messages on that call (in certain >>>>> situations) such as... >>>>> >>>>> Error Code: 502 Proxy Error. A software error occurred for a Windows >>>>> Internet extension application that is required for the current >>>>> >>>> operation. >>>> >>>>> >>>>> and >>>>> >>>>> Error 415 Unsupported Media Type >>>>> >>>>> Does anyone have an idea what this might be? Why it changed? If I swap >>>>> >>>> out >>>> >>>>> the latest version for 41 or 42, and change nothing else, it works >>>>> fine. >>>>> Can't find anything in docs or searches online. >>>>> >>>>> >>>> What is your configuration? >>>> >>>> I guess that those 500 and 415 responses are not from Tomcat. Are they >>>> from IIS? Is that one up-to-date? >>>> >>>> Do you have access log configured in Tomcat? Are those requests >>>> mentioned in Tomcat access log? >>>> >>>> Does the issue happen randomly? Can you reproduce it? >>>> >>>> >>>> Best regards, >>>> Konstantin Kolinko >>>> >>>> --------------------------------------------------------------------- >>>> 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 >> >> >
