SVGZ doesn't have the good encoding
Bug #179983 reported by
Popolon
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
BlueBream |
New
|
Undecided
|
Unassigned | ||
Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
Zope 3 |
Won't Fix
|
Undecided
|
Unassigned | ||
zope.contenttype |
Invalid
|
Undecided
|
Unassigned |
Bug Description
The SVGZ attachement at the end of this bug report is displayed in mozilla softwares as wrong, because :
The mime-type is well defined :
image/svg+xml
but the encoding is not defined and should be
gzip
on apache the following paramaters can be put in a .htaccess at the root of the web site, the second line should be enough for you (and on apache since at least 2.2.6) :
AddType image/svg+xml svgz
AddEncoding gzip svgz
The SVGZ wrongly displayed :
http://
The expected result (same file, different name) :
http://
Changed in malone: | |
status: | New → Triaged |
importance: | Undecided → Low |
Changed in zope3: | |
status: | New → Won't Fix |
To post a comment you must log in.
The mime-type of the attachment is set at upload time, using the mime-type that the uploading browser claims the file to be when POSTing.
So the problem is that the browser that uploaded it is setting the wrong mime-type, and Launchpad is then faithfully serving it as the mime-type it was told to.
So I don't think this is a Launchpad bug (although perhaps it would be useful for the person uploading the attachment to be able to override the mime-type that a browser auto-detects?).
(Btw, an encoding of "gzip" would be wrong here: the file itself is gzipped, as indicated by the "z" in "svgz". So its not just a transfer encoding, it's the actual content of the file. It would be wrong to tell the receiving browser that the file extension is "svgz", but then tell it to ungzip the contents before saving them, which is what your proposed Apache directives would do.)