Does not render SVG from .svgz without Content-Encoding: gzip

They should not serve svg files at Content-type: text/plain. Works in IE
because IE cheats and ignores content-type sometimes.

Bug is invalid.

See this link for info on MIME type for SVG <http://wiki.svg.org/index.php/MimeType>

Moving to Tech Evangelism.

Conforming summary to TFM item 10 at
http://www.mozilla.org/projects/tech-evangelism/site/procedures.html#file-new

This is invalid. Reporter, please read:

  http://www.mozilla.org/projects/svg/faq.html#source
  http://jwatt.org/svg/authoring/#server-configuration

It was quite clear from early on that this was a Tech Evangelism bug rather than
an SVG bug, since Comcast (a major US ISP) does not have the correct MIME type
set for SVG files. There's nothing an end-user can do to fix it, and moving it
from TE to SVG and marking it invalid certainly doesn't help the situation.

Reopening, clarifying summary, and moving back to TE.

(In reply to comment #5)
> There's nothing an end-user can do to fix it

Ah, okay. I didn't realise you were trying to get it fixed for a whole ISP. I
thought it was only for the reporter's own website. Nevertheless, those docs
should explain what needs to be done. Please note that it's not only the
MIME-type that's wrong. Servers should also send Content-Encoding: gzip for
gzipped .svgz files. (I don't know how that can be fixed for different versions
of IIS, so if anyone knows I would be *very* interested to hear from them.)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

On attempting to view Adobe's SVG demos, FF immediately throws an XML error, as
it's attempting to parse the gzipped SVG file as raw SVG, instead of
decompressing. The server appears to send as image/svg+xml, so I'm not sure if
it's the correct MIME type, but I'm not sure if it's supposed to recognise from
the extension. I should imagine it would probably work as a .svg.gz, but .svgz
doesn't appear to be directly recognised.

Example headers direct from the Adobe server are below.

HTTP/1.1 200 OK
Date: Mon, 12 Sep 2005 13:19:22 GMT
Server: Apache
Last-Modified: Mon, 22 Oct 2001 22:58:43 GMT
ETag: "3b61a-2bd1-3bd4a4a3"
Accept-Ranges: bytes
Content-Length: 11217
Connection: close
Content-Type: image/svg+xml

Reproducible: Always

Steps to Reproduce:
1. Attempt to load one of the Adobe SVG demos.
Actual Results:
An XML error, as the browser interpreted it as malformed XML.

Expected Results:
Internal decompression of the SVG file, and the correct interpretation of the
XML/SVG.

Thanks for taking the time to file a bug report Richard, but I'm afraid this is
invalid. Servers are also required to send the HTTP header:

Content-encoding: gzip

with gzipped SVG content. Attempts to convince Adobe to fix this have so far
been unsuccessful. The more people who contact them though, the higher the
chances I'd hope. See

http://www.jwatt.org/svg/authoring/#server-configuration

for more information.

Unfortunately, I had a feeling that would be the case, hence I dropped all the
headers in to make sure.

I'll drop an e-mail to Adobe. The more people who do, the more notice they
(eventually may) take.

Sorry for the misbug! :)

*** Bug 312037 has been marked as a duplicate of this bug. ***

*** Bug 320340 has been marked as a duplicate of this bug. ***

So let's get Adobe fix their server config.
--> Tech Evangelism, reopening.

tripod.com has this same problem. Submitted support request to them, but they rejected it with only a (useless) canned explanation.

Just retested, this is still the case.

Just sent them an email - so it's been a year with no change.

This is still an issue for home.comcast.net. It appears Comcast is using Netscape-Enterprise/4.1, not IIS or Apache.
I don't have a Comcast account, so I can't test this, but it's possible they are configured like a nice webhost and allow end-users to do the ".htaccess" fix? (http://wiki.svg.org/Server_Configuration:Apache) Yes, they aren't using Apache but from the Netscape-Enterprise docs:

"You may need to allow end users to access a subset of configuration options ...Two types of dynamic configuration files are supported by Netscape Enterprise Server: .htaccess and .nsconfig."
http://docs.sun.com/source/816-5654-10/esapuirf.htm#1004820

I think someone suggested this to me once before, but I couldn't remember so I tried again. I get this error when I try to upload the file:

550-The path or filename you have entered contains forbidden characters.
550-A filename may contain only alphabetic letters in capitals (A-Z) or lower
550-case (a-z) and the numbers 0-9. The symbols dash (-), underscore (_) and
550-dot (.) may also be used. A filename may NOT start with a dot or dash.
550 .htaccess: Forbidden filename

comcast != friendly web host

You know, I've seen many sites that do the same thing as Adobe. It might not be correct server behavior, but we still have quirks mode for HTML, don't we? This is a widespread error, and not fixing it will just decrease the ease of use for these files.

The SVG conformance standards specify that the client (ie, Firefox) "must specify "Accept-Encoding: gzip" on its request-header field and then decompress any gzip-encoded data streams that are downloaded from the server". But it doesn't say that if the content encoding header is missing it _mustn't_ try to detect the case automatically. Also, RFC 2616 mentions in section 19.3: "Although this document specifies the requirements for the generation of HTTP/1.1 messages, not all applications will be correct in their implementation. We therefore recommend that operational applications be tolerant of deviations whenever those deviations can be interpreted unambiguously."

Since the svg/svgz extensions are clearly defined, a gzip-encoded file is unambiguously distinguishable from an uncompressed SVG (or XML in general) document, and the special case to be treated is very restricted, I think the best behavior would be to detect svgz even if the server doesn't tell us.

IF ((the browser expects a SVG document according to the content type) OR (the file name ends with .svgz, case-insensitively)) AND it is not well-formed XML THEN check if it's a gzipped SVG document.

And by the way, loading a .svgz file from the disk _still_ doesn't work even in the latest FF3 beta, which is silly. The fix would be the same.

Would a list of broken SVG content around the web be useful?
I could put logging on the bookmarklet on http://steltenpower.com/svgopen/svgproxy.php ...

@Bogdan: Hear, hear.
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 want the users to be bugged by warning messages, it doesn't reflect well, even if not as badly as the page failing completely. That just reflects badly on Firefox. Adobe has got their hands on Flash now and has discontinued their plugin, so what do they care. Most existing SVG content is made for the Adobe plugin, ignoring the issue won't help anybody.
For the above to simply point a finger and say "It's their fault" fixes nothing, when Firefox can easily fix it.

Martin, I'm sorry but that is a simplistic statement.

See <http://bclary.com/log/2004/09/26/boot-camp-content-type> for an old article I wrote on this subject. Note <http://www.google.com/search?hl=en&lr=lang_en&ie=UTF-8&safe=off&as_qdr=all&q=%22internet+explorer%22+mime+site%3Asecuritytracker.com&btnG=Search&lr=lang_en> for some of the security vulnerabilities that this has caused Internet Explorer.

I agree that guessing the format of the incoming data is generally difficult and can be dangerous. But that doesn't mean that it can't ever be done safely and it's never a good idea to try.

Note that in this case it's _not_ the MIME type that it's supposed to be guessed, but the _encoding_. The server correctly specifies that it's serving a SVG document, it just neglects (or misuses) the encoding header (see last paragraph).

Two general observations: One, there aren't that many encodings—in your example session Mozilla only accepts two (plus the default “straight” encoding), so it wouldn't be that hard to write safe code for detection in the general case. (Though I'm still not sure it'd be a good idea in other cases that svgz.)

Second, the content encoding might be guessed by the server. I see no reason why blindly following the guessed encoding specified by the server is any less dangerous than guessing the encoding in the browser; from the point of view of whatever module does the parsing the two situations are usually indistinguishable. (Always remember I'm talking about content encodings, not content type, though the argument is half-valid in that case too.)

In this case, I actually suspect that's explicitly what happens with the server: it just has a set of svgz files (instead of svg), and the Adobe server just serves them without re-encoding them (thus, as far as it's concerned, it just serves data in the default encoding)*, and it detects based on extension that the mime type is svg. Since the server doesn't process the data for transmission, which is what content encoding is usually intended for), setting that header would be exactly the same guesswork from the server as from the browser. (The mime-type is also guesswork anyway, which is the valid half argument at the end of the previous paragraph.)

(Note that usually, as far as I know, the mime type is detected from the file served, and the encoding is picked by the server independently for the purpose of the transmission. SVGZ is a special case (with a few others) AFAIK. So it's half reasonable for someone to write a web server that never looks at the file for the purpose of determining the content encoding, and moreover always specifies the plain encoding for sending data. I think registering svgz as image/svg+xml+gz would have been much more logical than how it's done now.)

I have difficulty in seeing why, five years on, this issue is still not resolved.

Firefox is a world leader in displaying svg now, why do servers need to be tweaked to cope with svgz.

The basic problem seems to come from the sloppy way Adobe defined two identical mime types for different content.

 ".svg"=> "image/svg+xml",
 ".svgz"=> "image/svg+xml",

It looks like the world is stuck with that now. So how to get around it cleanly?

HTTP spec says that mime-type in "Content-type" should be authoritative but other methods can be used if it fails or is not available. Such techniques as file-extension (yuk) and initial bytes are permissible if a file type cannot be identified.

Requiring server to spoof transmission encoding does not seem like the best solution. It is a work around for the Adobe problem.

It would seem that it is legitimate within the spec to use a secondary method to distinguish between svg/svgz. Initial bytes would probably the more robust solution here since it would be very clear-cut and unambiguous.

svg and svgz are two distinct file types that unfortunately have been attributed the same mime-type.

The spec allows other techniques to be used. So why not?

(In reply to comment #11)
> I have difficulty in seeing why, five years on, this issue is still not
> resolved.

So do we. I guess after 5 years we need to conclude that Adobe are just not going to fix their servers.

>
> Firefox is a world leader in displaying svg now, why do servers need to be
> tweaked to cope with svgz.

Because the files are not served correctly.

> It looks like the world is stuck with that now. So how to get around it
> cleanly?

Fix the servers, everybody else serving SVG has managed this.

> Fix the servers, everybody else serving SVG has managed this.
This is what this bug was about (it's in Tech Evangelism).

Adobe has changed those examples to require their SVG viewer plugin.
And they discontinued support for that plugin.

So this bug is indeed invalid.

wontfix is probably more accurate I suppose since Adobe won't fix their servers.

Or at least they won't fix them so that they are usable without their plugin.

What "servers" are adobe supposed to change ? Adobe is history as far as svg(z) is concerned. Firefox does not use thier bug-ridden plug-in and they no longer support it.

 That should not stop the rest of the world using this excellent format.

The tech evangelism argument is long dead.

As far as I can see Content-encoding is a workaround. This would imply that it is an svg file that is being transmitted gzip encoded. That is not the case , it is svgz file that is already compressed that is served without change.

IMO this is a misuse of Content-encoding and gives other problems.

If I request sample.gz I do not need to send Content-encoding , only Content-Type: application/x-gzip

If I have to add extra headers to pretend there is a compression that is not being done it is because FF does not know what to do with svgz, as opposed to svg. It handles both identically, they are not identical.

If the server is to artificially add extra headers, it works fine until there is a 404 or other error at which point the headers no longer match.

Opera seems to deal with this mis-match, presumably by incorrectly ignoring "Content-encoding" . Firefox ,being more rigorous, shows an encoding error in place of the officially unreadable server error.

I'm perfectly happy with FF not fudging the content on the errors , this seems 100% std compliant. But I think the "fix the servers" response is not compliant since it is a mis-use of Content-encoding .

>> Fix the servers, everybody else serving SVG has managed this.

Yes everyone else has had to fudge this to get FF to display the content. That does not mean it is the correct solution.

This is from the SVG specification:

http://www.w3.org/TR/2008/WD-SVGMobile12-20080912/conform.html#ConformingSVGServers

There's no fudging. We expect servers to do exactly what it says.

(In reply to comment #16)
> What "servers" are adobe supposed to change ?

The ones serving the broken SVG demos.

> That should not stop the rest of the world using this excellent format.

And indeed it hasn't. Everyone else, as noted in comment 12, seems to be able to do this properly. Only Adobe can't manage it right.

I'm quite OK with WONTFIX on this since Adobe is being so intransigent. This bug ONLY deals with Adobe's brokenness; if you have problems with the way Firefox or Gecko handles content-type for SVG files otherwise, file a different bug and argue your case there.

re #17.

Thanks for a link to some definitive info. I stand corrected, I was confusing Content-Encoding and Transfer-Encoding .

Looks like FFx is doing the right thing.

I ran into this myself w/ Apache, where serving the header Firefox requires had to be done manually in config.
https://issues.apache.org/bugzilla/show_bug.cgi?id=31483#c2

"The SVG 1.1 Errata should clarify this issue, svg viewers should be able to
load gzipped svgz content no matter how it's loaded, svgz does not require a
content-encoding header to be loaded."

No errata is necessary it's stated clearly in the specification: http://www.w3.org/TR/SVG/conform.html#ConformingSVGServers

We'd oppose changing the SVG specification in the way suggested in comment 20.

Aight. Fair enough. The fix to Apache is fortunately fairly easy. I'm just surprised this wasn't part of my standard server config like a decade after this issue became widespread.
I hadn't really noticed it until now because most SVGs I was serving were pretty lightweight and I just used mod_deflate ☺