0005381: Checksum mismatch for ocaml-3.12-refman.html.tar.gz

Notes
(0006396) xleroy (administrator) 2011-12-20 09:37	I can confirm that, on our side, the file and its MD5 as written in MD5SUM agree, and moreover neither the file nor MD5SUM were changed after the release (Aug 29). If I download ocaml-3.12-refman.html.tar.gz using wget, I obtain the right file (length 526923) with the right MD5. If I download using "save to file" in Mozilla or Chrome, I get a different file of length 521527 and "tar tzf" in Ubuntu complains about that file, but "tar tzf" in MacOSX is happy with it. Safari, on the other hand, gives me the right file but strips the .gz from its name. This is all very confusing. Maybe the Web server at caml.inria.fr is wrongly configured or interacts bizarrely with clients that advertise more capabilities than wget. Suggestions or analyses from Web experts would be welcome.

(0006398) protz (manager) 2011-12-20 09:55	The server is sending an invalid file (it's not even possible to extract it) when talking to Firefox. Investigating.

(0006401) protz (manager) 2011-12-20 10:08	Firefox gets: HTTP/1.1 200 OK Date: Tue, 20 Dec 2011 08:57:28 GMT Server: Apache/2.2.16 (Debian) Last-Modified: Fri, 29 Jul 2011 13:33:47 GMT Etag: "176028-80a4b-4a93554bee4c0" Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/x-gzip Wget gets: HTTP/1.1 200 OK Date: Tue, 20 Dec 2011 08:58:41 GMT Server: Apache/2.2.16 (Debian) Last-Modified: Fri, 29 Jul 2011 13:33:47 GMT ETag: "176028-80a4b-4a93554bee4c0" Accept-Ranges: bytes Content-Length: 526923 Vary: Accept-Encoding Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: application/x-gzip What happens is Firefox, seeing gzip-compressed data, decides to de-compress it on the fly, because it's a standard practice to send responses over an HTTP channel compressed in gzip format. However, it still saves the file with the .tar.gz extension. Moreover, it looks like the data is improperly decompressed by Firefox. I'm puzzled as to it's a bug in Firefox or not. I think the server is sending borderlines HTTP headers.

(0006403) ygrek (reporter) 2011-12-20 10:24	When the client indicates `Accept-Encoding: gzip` the server compresses the tar.gz with gzip once more and answers with `Content-Encoding: gzip`. Probably the browsers are not very comfortable with this? Opera saved double-compressed file too, curl behaves as expected (with and without --compress). AFAIK it is a standard practice to disable compression for already compressed files..

(0006412) gerd (reporter) 2011-12-20 14:14	I meant something else. Apparently there are two versions of ocaml-3.12-refman.html.tar.gz: One from July 16, 2010, and one from July 29, 2011. The old one has been archived by the GODI system: http://ocaml-programming.de/godi-backup/ocaml-3.12-refman.html.tar.gz. [^] What probably happened is that the manual was updated when 3.12.1 came out. If I diff the files I get a number of differences in the wording. I do not criticize that this has been done (of course not), but rather that the same file name has been chosen. This is intransparent to the users (it is the first time this happened for a minor Ocaml update, so far I remember), and the packaging systems go crazy when there are two versions of the same file (and apparently, humans also do, see the previous notes). I'd not be surprised if other distributors also ran into the same problem, or did not even recognize that there was an update, and ship 3.12.1 with the old manual. Regarding the "save the gz file" issue: Historically, this never worked well because of a bug introduced in early Netscape versions (file.gz was saved as file w/ compression), and so servers had to work around this, and so newer browsers just duplicate the bug that is now considered "standard". The lesson: Never download a .gz file with a browser. It activates "workarounds" that are just wrong in 50% of the cases. Use wget or curl instead.

(0006415) protz (manager) 2011-12-20 14:23	Xavier, or anyone who can modify the server configuration: from https://bugs.launchpad.net/ubuntu/+source/apache/+bug/220171, [^] it looks like SetEnvIfNoCase REQUEST_URI .(?:gif\|jp?g\|png\|zip\|tar.gz\|t?gz\|bz2)$ no-gzip dont-vary in the Apache's .htaccess or httpd.conf should fix the download problem. http://httpd.apache.org/docs/2.0/mod/mod_deflate.html [^] seems to be pretty good too. I'll let others argue about the rewording issue.

(0006642) protz (manager) 2012-01-11 11:20	I think this is also responsible for http://caml.inria.fr/~xleroy/ [^] and others not being displayable (this website uses an unsupported form of compression).

(0006709) lefessan (developer) 2012-01-17 23:12	I tested on my own Apache server, that exhibits the same problem, and it is clear that the problem appears when a ".html." substring is found in the name of the archive. Renaming "ocaml-3.12-refman.html.tar.gz" to "ocaml-3.12-refman-html.tar.gz" solved the problem. Unfortunately, I have no direct access to caml.inria.fr

(0006736) doligez (manager) 2012-01-19 19:42	OK, I'm renaming the file to ocaml-3.12.1-refman-html.tar.gz and from now on I will refrain from changing the file without changing the version number. What should I do with the current file? Delete it? Restore the previous version? Leave it as it is? Also, should I also rename ocaml-3.12-refman.html.zip, or is it treated correctly by the servers and browsers?

(0006760) ygrek (reporter) 2012-01-20 15:45	I believe this is a webserver misconfiguration/bug - probably http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565626 [^] has something to do with this.

Issue History
Date Modified	Username	Field	Change
2011-10-23 14:33	gerd	New Issue
2011-12-20 09:37	xleroy	Note Added: 0006396
2011-12-20 09:37	xleroy	Status	new => feedback
2011-12-20 09:55	protz	Note Added: 0006398
2011-12-20 10:08	protz	Note Added: 0006401
2011-12-20 10:24	ygrek	Note Added: 0006403
2011-12-20 14:14	gerd	Note Added: 0006412
2011-12-20 14:14	gerd	Status	feedback => new
2011-12-20 14:23	protz	Note Added: 0006415
2012-01-11 11:20	protz	Note Added: 0006642
2012-01-17 23:12	lefessan	Note Added: 0006709
2012-01-17 23:12	lefessan	Assigned To	=> lefessan
2012-01-17 23:12	lefessan	Status	new => confirmed
2012-01-19 14:01	lefessan	Assigned To	lefessan =>
2012-01-19 19:42	doligez	Note Added: 0006736
2012-01-19 19:42	doligez	Assigned To	=> doligez
2012-01-19 19:42	doligez	Status	confirmed => feedback
2012-01-20 15:45	ygrek	Note Added: 0006760
2012-07-04 17:11	doligez	Status	feedback => resolved
2012-07-04 17:11	doligez	Resolution	open => won't fix

Relationships