Community
Participate
Working Groups
We have discovered a troubling error when running our RAP application when hosted on Tomcat. It is not trivial to reproduce, but happens eventually with moderate use of our RAP application. When our testers change perspectives a few times, we see errors in the browser (pasted below). This error occurs on both Firefox and IE, but seems to be easier to replicate on Firefox. Our testers intercepted the packets between the browser and Tomcat using Ethereal, and it does not appear to be a gzip error nor an error with the mismatch in request/response mime types. This error cannot be re-created using the Jetty web server... Only on Tomcat.
Can you provide a self running snippet that can be used to reproduce the problem? BTW what is the error? It is missing in the description.
Did you set an encoding explicitly in the build or leave it to default?
We have the same problem. I think it is the same error like this one: http://dev.eclipse.org/newslists/news.eclipse.technology.rap/msg04195.html http://dev.eclipse.org/newslists/news.eclipse.technology.rap/msg04242.html
Shown in Browserwindow: Could not evaluate javascript response: SyntaxError: illegal character ����������]o�0�����fR���i���lI�%��V�7E%�bh�?CHRE�a$�"��؏�c�+ȗ���m�W&N�P�b�C/�q�^��nb����$t�_R.���(�.��K-<)~��0�qt���ֶ���|O�3qCw��&� �]�G?�v���ȓ�n �Y�[��b�z��'���T��z]Q��*ꉢ^q~���b��Ŋ����*��|��y�&\�^>��3�)T�QAK��/���{<����&��'qz��.4c��過��o�0 ��8M�m!��(��)��H��@����Dt�=��~���<�މ �O��P��:�5B��F�!y�O���vACd�}\��c���'�����`�H6"#�Cޗt�e3r��� \��Y���KA�BdV��;�f4,� R���� Z��!2�i�r� i�hк4tE1 ��ј6�AZ���и�~��Y`B�dAI1r���(b0�b~ݟ����>��0t���Y]#0#h�%�Ua�54�� �. M��u���Y2�g i��huiP� dOCf=��߆4�h�� R� 5LK���Y���$$r ��ٝ=�;�!pf�3h�^-Q��z�4,�H�'~ڃ��h��ĵ+N��"��S��}��tm��,+9K6�#�p���CGkYL��@ը��g�1�A�設b׭6q�&FM_����Q��\: u_設j�-71V��o��qL�n�h���e�f)T��C�Q5���7gq���ԇ�(��76���iD7���:�p�,s����W���SG�� Firebug Console: Response Headers Server:Apache-Coyote/1.1 Transfer-Encoding: chunked Date: Fri, 08 May 2009 09:02:27 GMT Request Headers Host: 127.0.0.1:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Qooxdoo-Response-Type: text/plain Pragma: no-cache Cache-Control: no-cache X-Requested-With: qooxdoo X-Qooxdoo-Version: 0.7.4 (r16878) Referer: http://127.0.0.1:8080/demo/start Content-Length: 201 Cookie: JSESSIONID=BC2532F69BDB8826E2F247DDB4E6B04C
Markus, can you provide a self running snippet/project to reproduce the problem?
I tried, but I'm not able to reproduce the error. I'm not able to say do this and that and then the error occurs. So it is difficult to post a snippet. Maybe the browser expect characters (Javascipt/Html/XML?) but he get some binary data (image?).
This bug has been observed by many people now, still it is hard to reproduce. What we have so far: * We received a couple of such character cheese dumps as in comment #4 from users, most of them (but not all) contain the unicode replacement character (�, U+FFFD, ?) over and over. This character is shown when an application cannot render a certain code point. * The problem affects the initial HTML page, which arrives mangled at the client and is then cached. Something might go wrong during assembling, zipping, or encoding the initial page. To be sure, a wireshark log of a failed session may be helpful. To get such a log, access the application with a clean browser cache and receive the character garbage instead of the initial page. Since we couldn't reproduce the problem by ourselves so far, we still don't know what exactly is sent from server to client in this case.
After hours of tcp dump analysis, we know a bit more about the problem: * The client receives a response that is gzip-compressed, but the header "Content-Encoding: gzip" is missing. * Since the "Content-Type: html" header is set, the client tries to render the gzip stream as html which leads to the garbage. * It seems that this always happens in conjunction with chunked transfer encoding. The gzip compression is done by RAP, not Tomcat. I'm not sure under which circumstances Tomcat chooses chunked transfer encoding, but the reason might be a delayed output from the servlet. It is not clear whether Tomcat drops the Content-Encoding header when using chunked transfer encoding or if RAP fails to set the header in some weird cases which in turn also cause Tomcat to use chunked mode. As a workaround, it should help to turn off the gzip compression by RAP by adding the vm parameter -Dcompression=false. It should be possible to enable compression in Tomcat instead.
Wouldn't it make sense to turn off RAP-side compression be default? I would rather see this as a task for the web container task than for RAP.
First tests with [1] JVM parameter -Dcompression=false and [2] Tomcat's server.xml <Connector port="8080" protocol="HTTP/1.1" proxyPort="80" compression="on" are looking really good. They result in a HTML header such as HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: max-age=0, no-cache, must-revalidate Transfer-Encoding: chunked Content-Type: text/html Content-Encoding: gzip and I am quite confident that the browsers are cabable of decoding this combination of content-type and content-encoding. Without the two changes above the "Content-Encoding" was missing in some cases.
(In reply to comment #9) > Wouldn't it make sense to turn off RAP-side compression be default? I would > rather see this as a task for the web container task than for RAP. I agree, opened bug 285669 for this.
As bug 285669 is resolved now, I consider this bug fixed as well.
