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?
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
