Loading *.js.gz

[wlam]

I am using Smartclient v9.0 pro deployed on tomcat 7.0. Browser FF and Chrome

In my JSP, I have included the following tag

<isc:loadISC isomorphicURI="../isomorphic/" skin="EnterpriseBlue" includeModules="Charts"/>

and in my web.xml, I have added

    <servlet>
       <servlet-name>FileDownload</servlet-name>
       <servlet-class>com.isomorphic.servlet.FileDownload</servlet-class>
    </servlet>
    <servlet-mapping>
       <servlet-name>FileDownload</servlet-name>
       <url-pattern>/isomorphic/system/modules/*</url-pattern>
    </servlet-mapping>

in order to serve .js.gz, but it doesn't seems to work. From the developer console I only see .js files are requested, the response is the uncompressed js file. I remove the .js and leaving .js.gz in 'modules' folder just to make sure, that gave me 404 not found errors. Please let me know what I am missing.

[Isomorphic]

Most likely the FileDownload servlet is not involved because it is not registered at the right URL.

There are telltale server logs that appear when FileDownload is activated - just to be sure, modify log4j.isc.config.xml to set the default log level to DEBUG.

If you see FileDownload-related messages but there is no compression, please post the server log that shows the FileDownload messages.

[wlam]

I use a clean tomcat install for the following tests

Use this URL with cleaning browser cache each time

http://localhost:8080/examples/isomorphic/system/modules/ISC_Charts.js

1st test with both .js and .js.gz existing in the folder, js returned and the log showed, Chrome developer console said 189KB transferred, which is the size of .js not .js.gz

=== 2013-09-27 12:22:03,840 [ec-2] INFO  ISCInit - Auto-detected webRoot - using: C:\apache-tomcat-7.0.42\webapps\examples
=== 2013-09-27 12:22:03,841 [ec-2] INFO  ISCInit - Isomorphic SmartClient/SmartGWT Framework (v9.0p_2013-07-31/Pro Deployment 2013
-07-31) - Initialization Complete
=== 2013-09-27 12:22:03,886 [ec-2] INFO  RequestContext - URL: '/examples/isomorphic/system/modules/ISC_Charts.js', User-Agent: 'M
ozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36': Safari with Accept-E
ncoding header
=== 2013-09-27 12:22:03,889 [ec-2] DEBUG Download - request for file: C:\apache-tomcat-7.0.42\webapps\examples\isomorphic\system\m
odules\ISC_Charts.js
=== 2013-09-27 12:22:03,900 [ec-2] INFO  Download - done streaming: C:/apache-tomcat-7.0.42/webapps/examples/isomorphic/system/mod
ules/ISC_Charts.js

2nd test, remove .js.gz from the folder, I got 404

=== 2013-09-27 12:24:04,518 [ec-6] INFO  RequestContext - URL: '/examples/isomorphic/system/modules/ISC_Charts.js', User-Agent: 'M
ozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36': Safari with Accept-E
ncoding header
=== 2013-09-27 12:24:04,521 [ec-6] DEBUG Download - request for file: C:\apache-tomcat-7.0.42\webapps\examples\isomorphic\system\m
odules\ISC_Charts.js
=== 2013-09-27 12:24:04,522 [ec-6] INFO  Download - File C:/apache-tomcat-7.0.42/webapps/examples/isomorphic/system/modules/ISC_Ch
arts.js not found, sending 404

[Isomorphic]

Looks like the FileDownload servlet is working properly, you are just being misled by your tools.

The requested and returned file *does* have the extension .js and the tools *should* show the contents as uncompressed, because the compression is based on HTTP Accept-Encoding headers, not based on requesting an actual .js.gz file.

The tools are likewise showing the uncompressed size because that's what the browser actually has in memory. This does not mean that the file had that size as it was delivered over the network.

To verify compression is working, take a look at the HTTP headers in the response. If you see something like Content-Encoding: gzip, compression is active. If you want to be really, really sure, you can use a low-level packet inspector such as Wireshark.

[wlam]

Shouldn't I see an INFO message as below (ServletTools.java)

        if (compress) {
          Logger.download.info("Using gzipped form of request file", filePath);

          context.response.setHeader("Content-Encoding", "gzip");
        }

btw, I have wireshark capture if you want it.

[Isomorphic]

There are multiple compression codepaths - rather than analyzing decompiled source or packet-level analysis, start with the (very very easy) check of the HTTP headers.

[wlam]

Here is the response headers captured by Chrome

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: public
Last-Modified: Wed, 31 Jul 2013 07:40:41 GMT
Content-Type: application/javascript
Content-Length: 826330
Date: Fri, 27 Sep 2013 19:02:38 GMT

[Isomorphic]

That's definitive.

Your server seems to be using a mime-type of application/javascript for .js files, whereas it looks like we'd expect "text/javascript" and other synonyms. We should be recognizing "application/javascript" as well, so we'll fix that.

compression.compressableMimeTypes: text/html, text/plain, text/css, text/xml, application/xml, application/javascript, application/x-javascript, text/javascript, text/ecmascript, image/svg+xml

To verify this is the only problem, please add the following to server.properties and retest.

[wlam]

Thanks, it works.

=== 2013-09-30 08:20:23,893 [ec-8] DEBUG Download - request for file: C:\apache-tomcat-7.0.42\webapps\examples\isomorphic\system\modules\ISC_Charts.js
=== 2013-09-30 08:20:23,895 [ec-8] INFO  Download - Using gzipped form of request file: C:/apache-tomcat-7.0.42/webapps/examples/isomorphic/system/modules/ISC_Charts.js
=== 2013-09-30 08:20:23,903 [ec-8] INFO  Download - done streaming: C:/apache-tomcat-7.0.42/webapps/examples/isomorphic/system/modules/ISC_Charts.js

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: public
Last-Modified: Wed, 31 Jul 2013 07:40:41 GMT
Content-Encoding: gzip
Content-Type: application/javascript
Content-Length: 52051
Date: Mon, 30 Sep 2013 12:20:23 GMT

[henkiemaritz]

Thanks, I've added the server.properties seems to fix the issue. I'll test it in production tommorrow.

[Isomorphic]

This was fixed and should be available in the next nightly build.