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

Reply via email to