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)

1.8 Branch
enhancement

Tracking

()

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.
Assignee: nobody → xml
Component: General → XML
Product: Firefox → Core
QA Contact: general → ashshbhatt
Version: unspecified → 1.8 Branch
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
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.
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
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.
Assignee: xml → nobody
QA Contact: ashshbhatt → xml
Depends on: 52282
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.