Fix mimetypes usage in handlers
cloudooo includes its own mimes.types, so that it does not depend on system configuration and behave the same regardless of the underlying system, but the embedded mime.types have to be loaded explicitly by calling utils.loadMimetypeList() by each python process before using mimetypes module. This was not done for ooo and x2t handlers, so in practice they were depending on the system mime.types and the tests were written to expect the mimetypes from debian 10, but with debian 11 some mimetypes became different ( for example .bmp extension was guessed as image/x-ms-bmp [1] on debian 10 and image/bmp on debian 11 [2]), Theses changes: - include mime.types from debian 10 [3], but keeping the extra mimetypes for only-office documents (docy, ppty and xlsy) that were added in 0bb5fbdc (x2t: add handler, 2016-09-22) - change the handlers to call utils.loadMimetypeList(), it was only strictly necessary for ooo handler, but do it as well in x2t for consistency. - adjust some tests in testX2tHandler, because now that we have loaded mimetypes database the mimetype of xlsy is returned in metadata, so we have "application/x-asc-spreadsheet" and not just "xlsy" - add a few more test for xlsy and docy, because the magic based test just verify that they are zip files, these new tests also make a few assertions on the content of the zip files [1]: https://salsa.debian.org/debian/mime-support/-/blob/debian/3.62/mime.types#L677 [2]: https://salsa.debian.org/debian/media-types/-/blob/4.0.0/mime.types#L1804 [3]: https://salsa.debian.org/debian/mime-support/-/blob/debian/3.62/mime.types
Showing
This diff is collapsed.
Please register or sign in to comment