| • bzimport | |
| Feb 14 2009, 4:51 PM |
| F5437: oasis.diff | |
| Nov 21 2014, 10:29 PM |
Author: awen
Description:
The following file types should be added to the line application/zip in mime.types:
odg odt odp ods otg ott otp ots
Even the documentation contains examples using them for uploads:
http://www.mediawiki.org/wiki/Manual:$wgFileExtensions
Version: 1.3.x
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T44725 Multimedia file format support (tracking) | |||
| Open | Feature | None | T45154 Commons uploads: Support all LibreOffice/OpenOffice.org formats (and automatic conversion from Microsoft Office formats) | ||
| Open | Feature | None | T19497 Add oasis opendocument and oo.o legacy document to mime.types | ||
| Open | Feature | None | T4089 Whitelist OASIS OpenDocument file format | ||
| Resolved | None | T26230 Implement JAR detection |
WONTFIX. Every sysadmin can decide for him/herself which uploads to $wgFileExtensions. MediaWiki by default uses a very conservative set for security reasons.
awen wrote:
Sorry, you misunderstood me! I was in NO way suggesting to have them added to $wgFileExtensions. It is very reasonable to not add them there.
The suggestion was solely to add them to mime.types, so if the sysadmin chooses to add them to $wgFileExtensions it will actually work.
I don't see the reason for having the Openoffice.org type 1.x mime types listed in mime.types, while not having the OASIS mime types?
awen wrote:
oasis support in mime.types
Here is a patch against current trunk/phase3
Attached:
This looks bogus; if added they should list their actual types (eg application/vnd.oasis.opendocument.text) not application/zip.
anon.hui wrote:
(In reply to comment #6)
This looks bogus; if added they should list their actual types (eg
application/vnd.oasis.opendocument.text) not application/zip.
What to do about oo.o 1.x format, sxc stc sxd std sxi sti sxm stm sxw stw ?
According to /usr/share/file/magic (in redhat or ubuntu), it seem to be, application/vnd.sun.xml.xxx. It should also be changed accordingly?
50 string vnd.sun.xml. OpenOffice.org 1.x
62 string writer Writer
68 byte !0x2e document
68 string .template template
68 string .global global document62 string calc Calc
66 byte !0x2e spreadsheet
66 string .template template62 string draw Draw
66 byte !0x2e document
66 string .template template62 string impress Impress
69 byte !0x2e presentation
69 string .template template62 string math Math document
50 string vnd.oasis.opendocument. OpenDocument
73 string text
77 byte !0x2d Text
77 string -template Text Template
77 string -web HTML Document Template
77 string -master Master Document73 string graphics Drawing
81 string -template Template
73 string presentation Presentation
85 string -template Template
73 string spreadsheet Spreadsheet
84 string -template Template
73 string chart Chart
78 string -template Template
73 string formula Formula
80 string -template Template
73 string database Database
73 string image Image
anon.hui wrote:
/etc/mime.types in Ubuntu contains the following entries,
application/vnd.sun.xml.calc sxc
application/vnd.sun.xml.calc.template stc
application/vnd.sun.xml.draw sxd
application/vnd.sun.xml.draw.template std
application/vnd.sun.xml.impress sxi
application/vnd.sun.xml.impress.template sti
application/vnd.sun.xml.math sxm
application/vnd.sun.xml.writer sxw
application/vnd.sun.xml.writer.global sxg
application/vnd.sun.xml.writer.template stw
anon.hui wrote:
However, the command "file -bi" on Redhat or Linux, does return application/x-zip for those openoffice files.
So, there should be an option for sysadmin to put additional custom mime.types entries.
Letting sysadmin to edit the file "includes/mime.types" is not a good idea,
since it will decrease the maintainability, especially when upgrading the MediaWiki software.
The custom mime.types entries should be placed in a separate file. The file name may be specified in a variable, $wgCustomMimeTypes, for example.
anon.hui wrote:
Since "file -bi" on some Linux distribution does return application/x-zip for the zip archive,
then the x-zip should also be associated with the zip archive (in addition to application/zip) in includes/mime.types,
application/zip zip jar xpi
application/x-zip zip jar xpi
Patch looks wrong; our mime.types map already correctly lists the OpenDocument formats with their own types, and we have detection specifically for such files.
If adding the old legacy formats (as in comment 9) these should also be added with their own mime types, and detection should be added in MimeMagic::detectZipType(). (Do the old formats use the same system for embedding the mime type in the zip file header?)
anon.hui wrote:
(In reply to comment #12)
If adding the old legacy formats (as in comment 9) these should also be added
with their own mime types, and detection should be added in
MimeMagic::detectZipType(). (Do the old formats use the same system for
embedding the mime type in the zip file header?)
According to the magic file from redhat, the legacy formats use the same system
for embedding the mime type in zip file header.