desktop-packages team mailing list archive

[Bug Watch Updater <342863@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 23 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=308153.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2005-09-12T13:27:32+00:00 Lists-x wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/7

------------------------------------------------------------------------
On 2005-09-12T13:33:56+00:00 Jonathan Watt wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/8

------------------------------------------------------------------------
On 2005-09-12T13:40:33+00:00 Lists-x wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/9

------------------------------------------------------------------------
On 2005-10-11T13:42:29+00:00 Elmar-ludwig wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/10

------------------------------------------------------------------------
On 2005-12-15T03:53:59+00:00 Ajschult wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/11

------------------------------------------------------------------------
On 2006-02-18T12:36:34+00:00 Steffen Wilberg wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/12

------------------------------------------------------------------------
On 2007-01-17T03:12:29+00:00 John Drinkwater wrote:

Just retested, this is still the case.

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/14

------------------------------------------------------------------------
On 2008-03-01T17:09:25+00:00 Bogdan Butnaru wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/17

------------------------------------------------------------------------
On 2008-05-17T16:56:36+00:00 Martin Andersen wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/19

------------------------------------------------------------------------
On 2008-05-17T21:33:39+00:00 Bvb wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/20

------------------------------------------------------------------------
On 2008-05-18T10:49:45+00:00 Bogdan Butnaru wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/21

------------------------------------------------------------------------
On 2010-06-07T08:51:55+00:00 Ffux wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/24

------------------------------------------------------------------------
On 2010-06-07T09:06:29+00:00 longsonr wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/25

------------------------------------------------------------------------
On 2010-06-07T09:19:39+00:00 Steffen Wilberg wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/26

------------------------------------------------------------------------
On 2010-06-07T09:41:44+00:00 longsonr wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/27

------------------------------------------------------------------------
On 2010-06-07T09:43:18+00:00 longsonr wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/28

------------------------------------------------------------------------
On 2010-06-07T11:02:09+00:00 Ffux wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/29

------------------------------------------------------------------------
On 2010-06-07T14:38:58+00:00 longsonr wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/30

------------------------------------------------------------------------
On 2010-06-07T14:49:26+00:00 Bugzilla-graveyard wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/31

------------------------------------------------------------------------
On 2010-06-07T18:08:50+00:00 Ffux wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/32

------------------------------------------------------------------------
On 2014-12-03T13:47:12+00:00 Derek wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/36

------------------------------------------------------------------------
On 2014-12-03T15:19:19+00:00 longsonr wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/37

------------------------------------------------------------------------
On 2014-12-03T15:45:58+00:00 Derek wrote:

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 ☺

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/342863/comments/38


** Changed in: firefox
       Status: Unknown => Won't Fix

** Changed in: firefox
   Importance: Unknown => Medium

** Bug watch added: Apache Software Foundation Bugzilla #31483
   http://issues.apache.org/bugzilla/show_bug.cgi?id=31483

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/342863

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

Status in The Mozilla Firefox Browser:
  Won't Fix
Status in firefox package in Ubuntu:
  Invalid

Bug description:
  Ubuntu Intrepid 8.10, Firefox 3.0.7

  I am testing using the Adobe SVG samples at
  http://www.adobe.com/svg/examples.html.  Upon attempting to render any
  of them, I get:

    XML Parsing Error: not well-formed
    Location: http://www.adobe.com/svg/demos/chart.svgz
    Line Number 1, Column 1:

  It appears that Adobe has neglected to configure AddEncoding gzip
  .svgz, given that the result of

    $ wget --save-headers http://www.adobe.com/svg/demos/chart.svgz

  (with or without adding --header="Accept-Encoding: gzip") yields the
  following headers:

  HTTP/1.1 200 OK
  Date: Sat, 14 Mar 2009 17:11:17 GMT
  Server: Apache
  Last-Modified: Mon, 22 Oct 2001 22:58:43 GMT
  ETag: "2bd1-6d282ec0"
  Accept-Ranges: bytes
  Content-Length: 11217
  Cache-Control: max-age=21600
  Expires: Sat, 14 Mar 2009 23:11:17 GMT
  X-UA-Compatible: IE=7
  Keep-Alive: timeout=5, max=500
  Connection: Keep-Alive
  Content-Type: text/plain

  whereas the result of the same process with the examples at
  http://www.svgmaker.com/examples.htm (which all work with FireFox)
  contains the correct:

  Content-Type: image/svg+xml
  Content-Encoding: gzip

  headers.

  Yes, yes, let's all go tell Adobe (and so many others) to fix their
  server configuration.  OK, we should.  But there ought to be a client-
  side way to get Firefox to do the right thing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/342863/+subscriptions