Thanks again for the reply. I forgot to mention last night that in the tomcat logs, that particular call has a 200 status code. (like fiddler said too) It seems RestyGwt and fiddler both have issues decoding the response (in 53) - but I don't know why, and everything I've seen so far indicates they are very close in headers, etc.
Gwt is a framework that is used to compile Java code into javascript, but it also has other features including RPC / some server side handling/utilities. That seems to be all working here (in 53+). However, we're using RestyGwt and a simple proxy to handle our async (REST) calls from the client/gwt-app/javascript to our jetty server. Jetty has given us some trouble in the past with chunking but we never really got to the bottom of it (something about if the headers are over a certain length (due to cookies, for eg), things would fail - so cleaning the browser cache fixed it). We were skipping the content-length header on the request, but I tried not skipping it, skipping it on the response, and doing both - no change. I'm not an http expert - so I'm sorry if there are obvious things I'm missing or should be providing/debugging/etc. I'd be happy to research more, run some tests, etc - but I'm not sure where to go with this. We're pretty tied to Jetty at this point for our REST server - but I would love to try switching that out if possible. I'm not sure what else to do. On Tue, Dec 23, 2014 at 4:02 AM, André Warnier <a...@ice-sa.com> wrote: > Sean Dawson wrote: > >> 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 >> >> > Hi. > Thank you for the clarification above. > One more question (remember, people here know a lot about Tomcat - and > consequently java - but not necessarily about GWT) : from the GWT project > website, I got the impression that it is something that allows one to > develop browser client-side code, which subsequently runs in the browser, > not on the server. But your explanation above seems to indicate a > different thing, with some "GWT-based webapp" running on the server. > What is exactly running where ? are there "pieces" of GWT both in the > browser and on the server, which talk to eachother ? > (Apologies for my lack of knowledge of the GWT architecture.) > > In any case, the kind of error messages which you mention would seem to > indicate that there is some HTTP protocol violation occurring, in terms of > a conflict between sending a response (or a request) using a "chunked" > encoding of the body, but with a Content-length HTTP header preceding it. > These two things are mutually-exclusive, and if indeed they happen, then > Tomcat would be right to consider this as an overall HTTP protocol > violation, print an error and (perhaps) aborting the further sending of the > response (or acceptance of the request). > (I don't know if you need a further explanation regarding this "chunked > body encoding" and the other type, but if you do I'd be glad to provide.) > > And it may very well be, that what Tomcat does in such a case, varies > depending on the version, as I believe one of the "changes history" notes > indicated. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
