{"id":6,"date":"2007-03-17T22:40:10","date_gmt":"2007-03-18T03:40:10","guid":{"rendered":"http:\/\/wp.javatechniques.com\/blog\/squid-corrupts-jar-files\/"},"modified":"2007-06-25T13:16:33","modified_gmt":"2007-06-25T18:16:33","slug":"squid-corrupts-jar-files","status":"publish","type":"page","link":"http:\/\/javatechniques.com\/blog\/squid-corrupts-jar-files\/","title":{"rendered":"Squid Corrupts Jar Files?"},"content":{"rendered":"

In an attempt to speed up launching of a 3+ Mb WebStart application for users behind an overworked firewall, I installed the open-source Squid<\/A> web cache on a Linux machine inside the firewall. By configuring clients to load jars (and other content) through the Squid proxy, each jar file only had to be pulled through the firewall a single time. The resulting speed boost at peak usage times was dramatic.<\/p>\n

Several weeks after the cache was deployed, users began reporting startup failures on the morning after one of the application’s jar files was updated. The WebStart download window reported “Failed to load resource http:\/\/…”, and the Details<\/I> button on the subsequent Unable to launch<\/I> dialog revealed a “Corrupted JAR file at http:\/\/…” error. The application launched without error on machines outside of the firewall, and also worked fine inside the firewall if WebStart was configured to bypass the proxy.<\/p>\n

We eventually determined that the problem originated in an incomplete configuration of the Apache web server from which the jars were loaded. Under recent versions of Linux (and other unix-ish operating systems), Apache uses the contents of \/etc\/mime.types<\/CODE> to determine the value of the HTTP Content-type<\/CODE> header that is returned in the response to each HTTP GET request, based on the file name extension of the requested file or object. If no mime-type is found for a given extension, Apache reverts to a default specified in its configuration file. The standard Apache configuration (e.g., in \/etc\/httpd\/conf\/httpd.conf<\/CODE>) includes this segment:<\/p>\n

\r\n\r\n#\r\n# DefaultType is the default MIME type the server will use for a document\r\n# if it cannot otherwise determine one, such as from filename extensions.\r\n# If your server contains mostly text or HTML documents, \"text\/plain\" is\r\n# a good value.  If most of your content is binary, such as applications\r\n# or images, you may want to use \"application\/octet-stream\" instead to\r\n# keep browsers from trying to display binary files as though they are\r\n# text.\r\n#\r\nDefaultType text\/plain\r\n\r\n<\/pre>\n
Unfortunately, the default configuration of \/etc\/mime.types<\/CODE> does not<\/I> include an entry for the .jar<\/CODE> extension, so Apache will claim that jar files are plain text.<\/p>\n
WebStart happily ignores the value of the Content-Type<\/CODE> header, so this is normally not a problem. Squid, however, manages cached objects differently based on their content type. The result is that jar files may be saved in the Squid disk cache in such a way that alters their content.<\/p>\n
To fix this, it is necessary to tell Apache that jar files contain binary data. This can be done by finding the line in \/etc\/mime.types<\/CODE> that starts with application\/octet-stream<\/CODE> and adding jar<\/CODE> to the list of extensions. For example, the line in \/etc\/mime.types<\/CODE> might look like:<\/p>\n
\r\napplication\/octet-stream        bin dms lha lzh exe\r\n<\/pre>\n
Changing this to:<\/p>\n
\r\napplication\/octet-stream        bin dms lha lzh exe jar\r\n<\/pre>\n
and restarting Apache solves the problem.<\/p>\n
Note that this change will not force Squid to replace a corrupted jar file that it has previously retrieved. You can fix this by updating the names of the jar files or using Squid’s client<\/CODE> program to purge the jars.<\/p>\n","protected":false},"excerpt":{"rendered":"
In an attempt to speed up launching of a 3+ Mb WebStart application for users behind an overworked firewall, I installed the open-source Squid web cache on a Linux machine inside the firewall. By configuring clients to load jars (and other content) through the Squid proxy, each jar file only had to be pulled through … <\/p>\n
Continue reading “Squid Corrupts Jar Files?”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"open","template":"","meta":{"footnotes":""},"class_list":["post-6","page","type-page","status-publish","hentry","entry"],"_links":{"self":[{"href":"http:\/\/javatechniques.com\/blog\/wp-json\/wp\/v2\/pages\/6","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/javatechniques.com\/blog\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/javatechniques.com\/blog\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/javatechniques.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/javatechniques.com\/blog\/wp-json\/wp\/v2\/comments?post=6"}],"version-history":[{"count":0,"href":"http:\/\/javatechniques.com\/blog\/wp-json\/wp\/v2\/pages\/6\/revisions"}],"wp:attachment":[{"href":"http:\/\/javatechniques.com\/blog\/wp-json\/wp\/v2\/media?parent=6"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}