Bug 5246 - WebKit can't load svgz files from disk
: WebKit can't load svgz files from disk
Status: NEW
: WebKit
SVG
: 420+
: Macintosh Mac OS X 10.4
: P4 Normal
Assigned To:
:
: NeedsRadar, ReviewedForRadar, SVGHitList
:
:
  Show dependency treegraph
 
Reported: 2005-10-03 01:09 PST by
Modified: 2011-12-19 10:59 PST (History)


Attachments
First pass at svgz support (11.64 KB, patch)
2005-10-10 14:04 PST, Eric Seidel
darin: review-
Review Patch | Details | Formatted Diff | Diff
A test case for LayoutTests (216 bytes, image/svg+xml)
2009-06-03 14:28 PST, Eric Seidel
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-10-03 01:09:57 PST
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...
------- Comment #1 From 2005-10-03 01:26:39 PST -------
Another example:
http://www.pandimaniacs.com/index.php?mode=svg&lang=en
this one uses an object tag...
------- Comment #2 From 2005-10-08 03:06:57 PST -------
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.
------- Comment #3 From 2005-10-10 14:04:31 PST -------
Created an attachment (id=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.
------- Comment #4 From 2005-10-10 14:50:06 PST -------
(From update of attachment 4300 [details])
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
------- Comment #5 From 2005-10-11 08:42:46 PST -------
(From update of attachment 4300 [details])
I think this should be done in the decoder, not in the part.
------- Comment #6 From 2005-10-12 02:21:12 PST -------
(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()"?
------- Comment #7 From 2005-10-12 07:51:54 PST -------
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.
------- Comment #8 From 2005-10-12 08:14:40 PST -------
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.
------- Comment #9 From 2005-10-14 13:14:13 PST -------
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.
------- Comment #10 From 2005-12-13 00:20:55 PST -------
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.
------- Comment #11 From 2007-02-05 16:52:50 PST -------
It's really bad that we don't support local SVGZ files.
------- Comment #12 From 2007-09-30 11:07:36 PST -------
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.
------- Comment #13 From 2007-12-18 09:54:40 PST -------
(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?
------- Comment #14 From 2008-02-26 04:25:49 PST -------
It does not. Filed <rdar://problem/5765475>.
------- Comment #15 From 2008-02-26 10:38:06 PST -------
(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.
------- Comment #16 From 2008-02-26 11:00:58 PST -------
I couldn't find it.
------- Comment #17 From 2009-06-03 14:27:52 PST -------
Chromium fixed this.  I guess this still needs support from Mac OS X for Safari to work here?  Adding a test case.
------- Comment #18 From 2009-06-03 14:28:16 PST -------
Created an attachment (id=30925) [details]
A test case for LayoutTests
------- Comment #19 From 2009-06-03 14:29:36 PST -------
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
------- Comment #20 From 2011-08-19 11:50:38 PST -------
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
------- Comment #21 From 2011-08-19 12:40:40 PST -------
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.
------- Comment #22 From 2011-08-19 13:30:39 PST -------
(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.
------- Comment #23 From 2011-08-19 13:37:54 PST -------
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.
------- Comment #24 From 2011-10-31 11:04:24 PST -------
(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.