Ok after many hours, here's all the information as I know it - as clearly and thoroughly as I can give it...
One physical machine - Windows 7 Gwt 2.6.1 App deployed to tomcat 7 (either 52 or 53) built with maven 3.1.1 uses RestyGwt 1.4 uses ProxyServlet to pass REST calls to other process REST server deployed with Jetty 8.1.7 built with same maven uses RestEasy 3.0.8.Final Tomcat setup... - download apache-tomcat-7.0.5[2/3]-windows-x64.zip - extract - clear webapps dir - create conf/Catalina/localhost/ROOT.xml with: <Context docBase="C:\path\ROOT.war"> .. [app specific params] </Context> - start Chrome Version 39.0.2171.95 m - all history cleared between every run. With 52, all calls seem to work and return quickly, fiddler doesn't show any errors/warning. With 53, the one PUT call seems to return status code 0 on client (hard to debug, in RestyGwt/javascript), with fiddler running, PUT call seems to take a lot longer, get HTTP protocol violation report about Content-Length MUSTNOT be present, also when attempting to decode the response data: The HTTP response body was malformed - the chunked content is corrupt, chunk length was malformed Offset: 14. Type System.IO.InvalidDataException... I don't see anything in the tomcat logs, or the REST server ones, to indicate an issue. Most of the request/response data in each situation are the same, except... [Transformer view] working case: Response body: 142 bytes, Chunked is checked failure case: Response body: 133 bytes, Chunked is checked [Raw view] working case: Transfer-Encoding: chunked, Transfer-Encoding: chunked (seems to be listed twice) failure case: Transfer-Encoding: chunked, Content-Length: 133 Request seems to be identical in both cases (except for a different JSESSIONID/cookie value) What else I've done: - compared all the config files between both version - seem similar enough - copied ecj-4.3.1.jar from 52 and put it in as ecj-P20140317-1600.jar in 53 - problem still exists - copied the 2 jars in bin that changed between version, and all the libs from 52 install to 53 install (everything else in 53 being original install) - problem no longer exists - attempted to remote debug Gwt client, attempted to debug servlets, attempted to switch PUT to POST, attempted to run REST server in eclipse (with Jetty runner), compared log files - no more info gathered On Mon, Dec 22, 2014 at 4:12 PM, André Warnier <a...@ice-sa.com> wrote: > Sean Dawson 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. >> >> Sean, > a word of advice : for someone not on your system, and not immersed in > your application and your setup, your explanation of the configuration you > are using, what is where, and what happens where when, is less than clear. > That makes it more difficult to really help you. > In addition, whislt I have not consulted right now the corresponding > applicable RFCs, and have just browsed the starting page of GWT right now > for the first time, it seems to me that you are making some assumptions > that may not be valid, and may lead you to surmise the wrong thing or look > in the wrong place. > > I believe that everyone understands that you are trying to figure out why > your whole "thing" seems to work with some versions of Tomcat and not > others. > > As a couple of people have already mentioned, it does not seem guaranteed > that a PUT request to a webserver, no matter in what context, would always > return a response *body*. > You say : "fiddler says the call succeeded with a 200". > That is not exactly true : Fiddler (apparently) shows you that a response > was received from the webserver; that this response consists only of a HTTP > status line; and that this status line includes a status code 200, which > from a HTTP protocol perspective should mean "OK". Fiddler does not tell > you anything else. It does not know what happened after the PUT request > was received by Tomcat, nor if the webapp really succeded in doing what it > was supposed to do. It just shows you the content of the received status > line. > > A HTTP response consists of, in that order, > - a HTTP status line (always) > - possibly, immediately following the status line, some additional HTTP > response header lines > - possibly, a blank line followed by a response body (what you call "data") > > (So basically, a HTTP response /could/ consist of a single status line, > and be perfectly valid from a pure HTTP perspective - and thus from a > Tomcat HTTP server perspective). > > We are further guessing that the Fiddler which you are mentioning sits > between the browser and Tomcat - it is not extremely clear, because you are > also at other times talking about Jetty, then about a Proxy webapp, then > about RESTy calls which sometimes succeed and sometime not etc.. > And - at least as far as I am concerned- we are supposing that the GWT > application of which you are talking runs inside of a browser page, and > makes some kind of HTTP calls to Tomcat. We will also suppose that the > "webapp" which you occasionally mention, runs on that same Tomcat server, > and that it is the one supposed to answer these HTTP calls from the GWT > application which lives in the browser. > > Well, guess what ? unless I am deeply mistaken - which is always a serious > possibility - I do not believe that Tomcat per se contains any code which > actually handles a PUT request and responds to it. So in all likelihood, > it is that webapp which you barely mention which controls what the PUT > actually does on the server, and which also controls the response that is > being sent back to the browser (or not, as the case may be). > From other bits of your explanation, I also surmise that the GWT code in > the browser, after receiving the HTTP 200 status line response, expects > additional HTTP headers and/or a HTTP response body with data in it, that > it is not receiving such a response body, and that in consequence it > blocks, waiting for it. (Which may or may not be its expected behaviour, we > also don't know that.) > > Very little of all the above actually happens in Tomcat code, which in > this case merely passes things back and forth between the browser and the > web application. And this Tomcat code has no idea what your GWT code on > the one hand, and the webapp code on the other, expect from eachother > beyond the HTTP spec. So, as long as what goes through appears relatively > HTTP-standard, and as long as the webapp does not really misbehave (aka, > crash), Tomcat has no particular reason to log anything. > > And yes, it may be that there is some weakness in some version of Tomcat, > which would cause it under certain circumstances, to not respond as > expected when some behaviour that is not really part of the HTTP > specification is happening. And it is possible that that same code area > has been tweaked in other versions and responds differently. But if I was > you, I would not necessarily first focus my interest on Tomcat in such a > case. > > In other words, my suggestion would be that you add some logging on each > side (in the GWT code and in the webapp), in order to better understand > what is going on. > And if you then see something that leads you to believe that the webapp is > sending data back to the browser, but that Tomcat intercepts it and does > not forward it, then send back a question to the list, with additional > information about what you found out. > > All the guessing above is relatively hard work, and you could save us a > lot of it if you made some effort to describe things a bit better. > So the next time, maybe add a little schema of your setup ? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
