308153 - adobe.com - svgz files served without "Content-encoding: gzip", resulting in an XML parsing error

Status: VERIFIED WONTFIX

(Tech Evangelism Graveyard :: English US, defect)

Description

[Richard Aspden]

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.

Comment 1

[Jonathan Watt [:jwatt]]

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.

Comment 2

[Richard Aspden]

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! :)

Comment 3

[Elmar Ludwig]

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

Comment 4

[Andrew Schultz]

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

Comment 5

[Steffen Wilberg]

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

Comment 6

[John Drinkwater (:beta)]

Just retested, this is still the case.

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

Comment 7

[Bogdan Butnaru]

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.

Comment 8

[Martin Andersen]

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

Comment 9

[Bob Clary [:bc] (inactive)]

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.

Comment 10

[Bogdan Butnaru]

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

Comment 11

[ffux]

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?

Comment 12

[Robert Longson [:longsonr]]

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

Comment 13

[Steffen Wilberg]

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

Comment 14

[Robert Longson [:longsonr]]

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

Comment 15

[Robert Longson [:longsonr]]

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

Comment 16

[ffux]

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.

Comment 17

[Robert Longson [:longsonr]]

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.

Comment 18

[Chris Lawson (gone)]

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

Comment 19

[ffux]

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.

Comment 20

[nemo]

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

Comment 21

[Robert Longson [:longsonr]]

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.

Comment 22

[nemo]

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 ☺