SVGZ doesn't have the good encoding

Bug #179983 reported by Popolon
4
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://launchpadlibrarian.net/11125154/gnuplot.sin.svgz

The expected result (same file, different name) :
http://popolon.free.fr/romanov.svgz

Tags: lp-bugs
Revision history for this message
Andrew Bennetts (spiv) wrote :

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.)

Revision history for this message
James Henstridge (jamesh) wrote :

Actually, we are using Zope's zope.app.content_types.guess_content_type() function here, and it returns "image/svg+xml" for such a file.

There are probably two parts here:

1. get proper Content-Encoding support in the librarian. We have a bug for this but I don't recall its ID.

2. Work out some way to mark .svgz and similar files with "Content-Encoding: gzip".

Revision history for this message
Florent (florent.x) wrote :

Same difficulties trying to use SVGZ images with Zope3.

There's no easy way to set the header "Content-Encoding: gzip" for a file object which is gzipped.

See bug #174204 for a proposed solution.
IMHO this solution may apply to the "zope.app.file.interfaces.IFile" too.
We already use the "contentType" attribute.
Let's add a "contentEncoding" optional attribute.

Curtis Hovey (sinzui)
Changed in malone:
status: New → Triaged
importance: Undecided → Low
Tres Seaver (tseaver)
Changed in zope3:
status: New → Won't Fix
Revision history for this message
Robert Collins (lifeless) wrote :
Revision history for this message
Colin Watson (cjwatson) wrote :

The zope.contenttype project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope.contenttype.

Changed in zope.contenttype:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.