Open
Bug 319690
Opened 19 years ago
Updated 2 years ago
[RFE] Display the actual reason gzip compressed SVG images do not work
Categories
(Core :: XML, enhancement)
Tracking
()
NEW
People
(Reporter: mikko.rantalainen, Unassigned)
References
(Depends on 1 open bug, )
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051208 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051208 Firefox/1.6a1 Many many web sites serving SVG content use in fact gzip compressed SVG images and do not correctly label all the namespaces used. Both errors are due the fact that Adobe SVG Viewer automatically & quietly fixes both these errors. As both of these are errors I'm not requesting Mozilla to accept these incorrectly authored and transferred images but instead Mozilla should report the error with a bit more information. Reproducible: Always Steps to Reproduce: 1. Go to http://www.adobe.com/svg/demos/chart.svgz Actual Results: XML Parsing Error: not well-formed Location: http://www.adobe.com/svg/demos/chart.svgz Line Number 1, Column 1: � Expected Results: Possibly the same output but in addition a text (preferably not a modal dialog but it's better than nothing) saying something along the lines: "This image cannot be displayed because of errors. Server failed to inform BROWSER_STRING about optionally used compression or the image has been authored incorrectly - for example, a namespace has been left undeclared." SVG will not get wider acceptance as long as it *seems* to a casual user that the error is in Firefox instead of content author. Whitness multiple duplicates about the above issues. The extra error message should be displayed every time there's an XML parse error and the content-type is image/svg+xml, possibly for some other content-types that SVG image have been served with.
Updated•19 years ago
|
Assignee: nobody → xml
Component: General → XML
Product: Firefox → Core
QA Contact: general → ashshbhatt
Version: unspecified → 1.8 Branch
Updated•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 1•18 years ago
|
||
The problem with this error is that while gzip-compressed SVG is legal, there is currently no mimetype to identify it. The question is, would it be better for Firefox to try decrypting the file quietly, declare an error message, or maybe someone should look into getting a mimetype for svgz?
Reporter | ||
Comment 2•18 years ago
|
||
No, the correct MIME-type for SVG is always image/svg+xml. However, if you send SVG with GZIP compression, you're supposed to tell about that fact via Content-Encoding header. See bug 157514 comment 6: > [...] add the following to a .htaccess file [...] > AddType image/svg+xml .svg > AddType image/svg+xml .svgz > AddEncoding x-gzip .svgz That results to following headers being sent by the server for a .svgz file: Content-Type: image/svg+xml Content-Encoding: x-gzip This bug is about telling the user that it's the server administrator that has made the mistake, not the Mozilla/Firefox. Note that it would be *incorrect* behavior to automatically fix the problem. It might be acceptable to prompt the user if such error recovery should take place. File a new bug for that if you want it.
Reporter | ||
Comment 3•18 years ago
|
||
See also: SVG 1.1 Specification (W3C Recommendation) http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers "Specific criteria that apply to both Conforming Static SVG Viewers and Conforming Dynamic SVG Viewers: [...] SVG implementations which support the HTTP protocol must correctly support gzip-encoded SVG data streams according to the HTTP 1.1 specification [RFC2616]; thus, the client must specify "Accept-Encoding: gzip" [HTTP-ACCEPT-ENCODING] on its request-header field and then decompress any gzip-encoded data streams that are downloaded from the server. If the implementation supports progressive rendering, the implementation should also support progressive rendering of compressed data streams."
I like the idea of putting more users to work in evangelizing this way
Comment 5•16 years ago
|
||
I think the correct way to handle it is to display the image, but to also produce an informative error, that way the user is less inconvenienced, but the server admin sees it in his interest to fix, as opposed to silent log warnings. If there are multiple images, still only produce one error, but mention the number of failed images. After all, the user doesn't care about server settings, he/she just want to see the images, and the server admin doesn't the users to be bugged by warning messages, it doesn't reflect well, even if not as badly as the page failing completely.
Updated•15 years ago
|
Assignee: xml → nobody
QA Contact: ashshbhatt → xml
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•