On Mon, Dec 22, 2014 at 3:01 PM, David kerber <dcker...@verizon.net> wrote:
> On 12/22/2014 2:56 PM, Sean Dawson wrote: > >> So it works with all of them up to _52 but fails for all of them after >> that. >> >> I had a theory related to tomcat creating a webapps/ROOT dir in the newer >> versions that it didn't in the older one (when pointing to the war from >> Catalina/local/ROOT.xml) as a possible difference/change but _52 does this >> and it works there. >> >> We have a fairly simple (java servlet) proxy to pass the gwt REST requests >> along - is there anything I could look at... redirects, (not) caching >> params, etc ? >> >> Will have a look at the changes to the config files between working and >> non-working tomcat installs - and also the release notes. >> > > How about changing the PUT to a POST, and see what that does for you? > > Similar result - 200 status, not proceeding - however fiddler seems to show some data. Will remote debug this to see if we're making it to onSuccess or onFailure (doubt it since it should either make another REST call, or show an exception message). On that call, Fiddler said Content-Length response header MUSTNOT be present when Transfer-Encoding is used. In the release notes between _53, here's the only thing I saw that I thought applied to our situation... 56190: The response should be closed (i.e. no further output is permitted) when a call to AsyncContext.complete() takes effect. (markt) Still going to check config file diffs. > > >> >> On Mon, Dec 22, 2014 at 2:15 PM, Sean Dawson <seandawson2...@gmail.com> >> wrote: >> >> >>> Am working on testing the 8 versions between the one that works and the >>> one that doesn't. >>> >>> We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far >>> as >>> we've tested) - restygwt REST calls to another process (jetty server - >>> RestEasy) work up to the point of that PUT request (which isn't alot of >>> them, but it's getting to the server and some succeed). There's almost no >>> info to go on when the gwt app doesn't proceed - fiddler says the call >>> succeeded with a 200 - but no data returned - and so the gwt app that >>> should proceed on onSuccess or onFailure, does not. So with the restygwt >>> async calls, we're not receiving anything back - despite fiddler claiming >>> that the call completed with 200 status (this can all be on the same >>> machine - but once you put the two processes or different ones using >>> different client browsers - sometimes get the other messages indicated). >>> So the problem might lie with RestyGwt - but that's not what changes >>> between the working and non-working scenario. >>> >>> Thanks for info from the spec. >>> >>> >>> >>> On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder < >>> hassan.schroe...@gmail.com> wrote: >>> >>> On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson <seandawson2...@gmail.com> >>>> wrote: >>>> >>>> In any case, people do it - and it was working before. >>>>> >>>> >>>> Uh, "people do" lots of objectively wrong things in web development, >>>> and "works in some circumstances" ≠ "adheres to the spec" :-) >>>> >>>> My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is >>>> that there's no reason to expect a response-body from a PUT, even >>>> if the mention of returning either 200 or 204 is a bit ambiguous. >>>> >>>> So it wouldn't surprise me to see a server implementation discard a >>>> response-body from a PUT as invalid. >>>> >>>> FWIW, >>>> -- >>>> Hassan Schroeder ------------------------ hassan.schroe...@gmail.com >>>> http://about.me/hassanschroeder >>>> twitter: @hassan >>>> >>>> --------------------------------------------------------------------- >>>> 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 > >
