Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005381OCamldocumentationpublic2011-10-23 14:332015-12-11 19:19
Assigned Todoligez 
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version3.12.1 
Target VersionFixed in Version 
Summary0005381: Checksum mismatch for ocaml-3.12-refman.html.tar.gz
DescriptionObviously, this file was modified in the download directory, because the checksum changed recently.

I do not know the reason, and can only speculate: Maybe the site was hacked, and an intruder replaced the file. Maybe there was a patch release under the same file name.
Additional InformationIf the change is because of a patch release, please don't do this. All distributors run into problems when a file is updated under the same name, because we cannot distinguish between intentional and non-intentional changes, and our distribution mechanisms do not handle this type of change well. Either the file is rejected because an intrusion is suspected, or the update is just ignored and not seen. Also, the replication mechanisms are sometimes confused. I'm reporting as GODI maintainer, but I know this problem exists basically everywhere in the one or other form.

Workaround: add a patch version number to the file.
TagsNo tags attached.
Attached Files

- Relationships
related to 0006022resolvedshinwell Strange tar file for Caml-Light documentation 

-  Notes
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 is wrongly configured or interacts bizarrely with clients that advertise more capabilities than wget. Suggestions or analyses from Web experts would be welcome.
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.
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.
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..
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: [^]

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.
protz (manager)
2011-12-20 14:23

Xavier, or anyone who can modify the server configuration: from, [^] 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. [^] seems to be pretty good too. I'll let others argue about the rewording issue.
protz (manager)
2012-01-11 11:20

I think this is also responsible for [^] and others not being displayable (this website uses an unsupported form of compression).
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
doligez (administrator)
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, or is it treated correctly by the servers and browsers?
ygrek (reporter)
2012-01-20 15:45

I believe this is a webserver misconfiguration/bug - probably [^] 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
2013-06-03 16:14 protz Relationship added related to 0006022
2015-12-11 19:19 xleroy Status resolved => closed
2017-02-23 16:35 doligez Category OCaml documentation => Documentation
2017-02-23 16:44 doligez Category Documentation => documentation

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker