Bug 5246 – WebKit can't load svgz files from disk

• Component: SVG
• Status: RESOLVED WONTFIX

[Eric Seidel (no email)]

WebKit+SVG does not handle svgz properly

http://www.svgmaker.com/examples.htm

has several examples of SVGZ content.  Somehow we need to detect that the content is gzip'd and stick a 
decoder in place to decode it.  I'm not sure how we'll do this, perhaps recognize the gzip header...

[Eric Seidel (no email)]

Another example:
http://www.pandimaniacs.com/index.php?mode=svg&lang=en
this one uses an object tag...

[Eric Seidel (no email)]

So my first look at this leads me to believe that this is likely best done down in Foundation in NSURL.  
NSURL already knows how to decode gzip streams before passing them on to the client, it just would need 
to be made aware of SVG.

However, that's not a very good option for the open source community, so we may need to find some sort 
of temporary solution until foundation can be enhanced and an updated foundation can be made 
available.

[Eric Seidel (no email)]

Created attachment 4300 [details]
First pass at svgz support

This still seems to have some sort of race condition, which often causes the
load to fail.  I'm not yet sure why.

[Eric Seidel (no email)]

Comment on attachment 4300 [details]
First pass at svgz support

A patch from this weekend....

Basically this hacks the KHTMLPart to try to decode any data in the main
resource that looks like gzip.	I'm not sure this is the "best" way to do this,
but it works, and is a starting point for discussion.

There seems to also still be a race condition with the load, wherby sometimes
the document parse fails.  I'm probably getting an early 0 length write, and
should likely be keying my idea of "this is the first write" and thus
GZipInflater construction off of something other than the presence or absense
of d->m_decoder

[Darin Adler]

Comment on attachment 4300 [details]
First pass at svgz support

I think this should be done in the decoder, not in the part.

[Eric Seidel (no email)]

(In reply to comment #5)
> (From update of attachment 4300 [details] [edit])
> I think this should be done in the decoder, not in the part.
> 

My concern with making this part of the Decoder had been "inheritance", since Decoders are shared 
between parts (child parts inherit their parent's Decoders sometimes).  I also had concerns about write() 
calls being passed through the decoder and gunziped unexpectedly.

It's possible for me to make the code part of the Decoder class, but not have the execution part of the 
decode() method... This solution would still require nearly identical changes to KHTMLPart, however 
instead of creating a GZipInflater object, I would set a bool somewhere, and call "inflate" on the 
decoder, before passing the inflated string back to the decoder (a second time) for decoding (in decode
()).

So given those concerns, would you still like this to be part of Decoder?  And if so, would you be OK 
with it being a separate method "inflate()" on Decoder, or were you suggesting I make this part of 
"decode()"?

[Nicholas Shanks]

The error is actually on the website, not here. It is not sending the correct Content-Encoding header.
See http://wiki.mozilla.org/SVG:MIMEType for info, see http://web.nickshanks.com/safari/tiger.svgz for 
an example that works fine in Safari. The non gzipped version is at tiger.svg in the same directory.

Now another bug is that DrawTest and Safari don't accept gzipped svg documents dragged onto their 
icons or make them selectable from the open dialog.

[Nicholas Shanks]

I just want to clarify:  I recommend NOT 'fixing' this.

Safari is a significant browser for people who care about standards (and thus are using SVG). When Safari 
ships with SVG support, SVG authors will test against it. Because that number is so small at the moment it 
is best to force them into the correct practice of specifying a Content-Encoding header for gzipped 
documents. If you do the wrong thing here, by accepting mis‐specified encodings and trying to work 
around it, you are HURTING the future of the web.

Safari in it's current state handles gzipped SVG just fine when the document is sent with the correct HTTP 
headers. There is nothing that needs fixing.

[Eric Seidel (no email)]

Darin and I discussed this.  WinIE already allows this for the local html case... we think that although it 
might be a bit "non-standard" it makes sense to support this remote image/svg+xml sent as gzip case.  
Even if they don't specify the correct ContentEncoding.

I'll move my logic into Decoder and resubmit.

[Eric Seidel (no email)]

Actually, we do handle it "properly".  FireFox has made an active choice not to support svgz w/o the 
correct Content Ecoding header either.  There still remains a question about supporting local svgz 
however.

[Eric Seidel (no email)]

It's really bad that we don't support local SVGZ files.

[Eric Seidel (no email)]

This may be automagically supported in Leopard if LaunchServices provides us with proper mime type and fake headers.  At least when I last talked to the UTI guy at Apple he seemed to suggest such was possible.  I believe this bug has a corresponding Radar which may even be assigned to the launch services team.  Adding the "NeedsRadar" keyword for someone to find and associate said Radar.

[David Kilzer (:ddkilzer)]

(In reply to comment #12)
> This may be automagically supported in Leopard if LaunchServices provides us
> with proper mime type and fake headers.  At least when I last talked to the UTI
> guy at Apple he seemed to suggest such was possible.  I believe this bug has a
> corresponding Radar which may even be assigned to the launch services team. 
> Adding the "NeedsRadar" keyword for someone to find and associate said Radar.

Does this work in Leopard now?

[Alexey Proskuryakov]

It does not. Filed <rdar://problem/5765475>.

[Eric Seidel (no email)]

(In reply to comment #14)
> It does not. Filed <rdar://problem/5765475>.
> 

There is another radar, asking for launch services to send us the headers/mimetype? (not even sure how that would work) correctly when opening an svgz file.  It was in the CoreTypes component long ago.

[Alexey Proskuryakov]

I couldn't find it.

[Eric Seidel (no email)]

Chromium fixed this.  I guess this still needs support from Mac OS X for Safari to work here?  Adding a test case.

[Eric Seidel (no email)]

Created attachment 30925 [details]
A test case for LayoutTests

[Eric Seidel (no email)]

Bugzilla doesn't send the "right" headers for svgz files, so the test fails in bugzilla (and will always fail).  It passes on disk for Chromium now, but not Safari.
http://code.google.com/p/chromium/issues/detail?id=9936

[Charles Pritchard]

SVGZ support is still mixed. The issue seems to be that SVGZ files are occasionally passed through XML parsing before sniffing the first bytes. The first bytes should -always- be sniffed. Chromium cross-link:
http://code.google.com/p/chromium/issues/detail?id=76968

[Eric Seidel (no email)]

SVGZ files work fine on the web, when the site is configured correctly:
https://jwatt.org/svg/authoring/

SVGZ files could work fine on disk if LaunchServices provided the right information.  It's unclear if radar 5765475 has been solved.

[Charles Pritchard]

(In reply to comment #21)
> SVGZ files work fine on the web, when the site is configured correctly:
> https://jwatt.org/svg/authoring/

Yes, but the specification dictates mime magic. And this corresponds well with blob and data URIs, do not need to specify the svgz content-type in order to work (per spec). I realize that svgz works well when the content type is specified on a server. If proper mime handling were in place, it'd work in all cases.

[Eric Seidel (no email)]

It sounds like what you're asking for is content sniffing.

.svgz is a file extension which requires the server to be set up correctly.  Similarly to serving a .html.gz file and expecting it to render correctly. :)  I assume you wouldn't argue that when a server hands us a .html file with something that looks like a gzip header we should try decoding it and rendering it "just in case". :)

.svgz files on local disk are a slightly different since there isn't really a server in place to set-up correctly.  Which is what this bug is about.  On Mac OS X, local .svgz handling should be fixable in the OS.

[Charles Pritchard]

(In reply to comment #23)
> It sounds like what you're asking for is content sniffing.
> .svgz files on local disk are a slightly different since there isn't really a server in place to set-up correctly.  Which is what this bug is about.  On Mac OS X, local .svgz handling should be fixable in the OS.



The issue also appears with blob and data uris.

[Karl Dubost]

Tested in 


A local SVG file
file:///Users/karlcow/Downloads/svg_logo.svgz

All of them failed with 

Safari, Chrome
  This page contains the following errors:
  error on line 1 at column 1: Encoding error
  Below is a rendering of the page up to the first error.

Firefox
  XML Parsing Error: not well-formed
  Location: file:///Users/karlcow/Downloads/svg_logo.svgz
  Line Number 1, Column 1:

file:///Users/karlcow/Downloads/svg_logo.svg is working correctly. 
Should we close this?