Bug 7476 – WebKit does not handle invalid MIME types for SVG

• Status: RESOLVED
• Resolution: WONTFIX
• Component: SVG

[David Kilzer (:ddkilzer)]

I'm pretty sure this topic has been discussed (at length) on IRC, the mailing list and elsewhere, but I'm creating this bug is to track issues with invalid MIME types returned for SVG images.

[David Kilzer (:ddkilzer)]

This web page links to two SVG images with an invalid MIME type of image/svg-xml (note "-" instead of "+" in the MIME type).

http://fudel.net/svg/svgtest.html

Here is output from "HEAD" (the Perl script from libwww-perl) for one of the SVG images:

$ HEAD http://fudel.net/svg/test/pixel-chaos-ai10-nb.svg
200 OK
Connection: close
Date: Sun, 26 Feb 2006 13:53:10 GMT
Accept-Ranges: bytes
ETag: "a7cf69-4e0b9-4282199f"
Server: Apache/1.3.33 (Unix)
Content-Length: 319673
Content-Type: image/svg-xml
Last-Modified: Wed, 11 May 2005 14:41:35 GMT
Client-Date: Sun, 26 Feb 2006 13:53:11 GMT
Client-Peer: 212.227.119.80:80
Client-Response-Num: 1
X-Pad: avoid browser bug

[Eric Seidel (no email)]

if bug 10361 was resolved, we could use that to report invalid mime types to the content authors, while still supporting rendering them for the user.

I think we need to just go ahead and support this though. :(

[Eric Seidel (no email)]

So I coded up a nice fix for this.

But now I hit this assert:
=================
ASSERTION FAILED: self == [[self page] mainFrame] || m_frame->ownerElement() (/Stuff/Projects/WebKit/WebCore/bridge/mac/WebCoreFrameBridge.mm:1015 -[WebCoreFrameBridge installInFrame:])
=================

when viewing http://www.mobiusportal.com/

I expect it's because they try to dynamically insert an embed which references a broken SVG document.  I bet that is causing us to go down a code path we have not gone down before.

[Eric Seidel (no email)]

Created attachment 10003 [details]
simple fix

this is the simple fix which I did to prove that I wasn't crazy (after I noticed it start crashing at mobiusportal.com

[Eric Seidel (no email)]

Created attachment 10004 [details]
nicer fix & frame.cpp cleanup (ignoring whitespace)

[Eric Seidel (no email)]

Created attachment 10005 [details]
nicer fix (including whitespace changes)

[Darin Adler]

Comment on attachment 10004 [details]
nicer fix & frame.cpp cleanup (ignoring whitespace)

Looks generally fine, but this won't compile:

+    return (mimeType == "image/svg+xml");
+         || mimeType == "image/svg-xml" // invalid, Adobe SVG Viewer compatibility
+         || mimeType == "image/xml+svg"); // invalid, Adobe SVG Viewer compatibility

Also, we should have some tests of these MIME types -- we have http tests that can test this sort of thing.

-            d->m_decoder->setEncodingName(d->m_encoding.latin1(),
-                d->m_haveEncoding ? Decoder::UserChosenEncoding : Decoder::EncodingFromHTTPHeader);
+            d->m_decoder->setEncodingName(d->m_encoding.latin1(), d->m_haveEncoding ? Decoder::UserChosenEncoding : Decoder::EncodingFromHTTPHeader);

The above does not look like an improvement. The old formatting looks better.

[Eric Seidel (no email)]

(In reply to comment #7)
> (From update of attachment 10004 [details] [edit])
> Looks generally fine, but this won't compile:
> 
> +    return (mimeType == "image/svg+xml");
> +         || mimeType == "image/svg-xml" // invalid, Adobe SVG Viewer
> compatibility
> +         || mimeType == "image/xml+svg"); // invalid, Adobe SVG Viewer
> compatibility
> 
> Also, we should have some tests of these MIME types -- we have http tests that
> can test this sort of thing.
> 
> -            d->m_decoder->setEncodingName(d->m_encoding.latin1(),
> -                d->m_haveEncoding ? Decoder::UserChosenEncoding :
> Decoder::EncodingFromHTTPHeader);
> +            d->m_decoder->setEncodingName(d->m_encoding.latin1(),
> d->m_haveEncoding ? Decoder::UserChosenEncoding :
> Decoder::EncodingFromHTTPHeader);
> 
> The above does not look like an improvement. The old formatting looks better.
> 

OK.

What you listed does actually compile with GCC.  Maybe it won't with other compilers however.

Eventually I'll find some time to make a test case or two and re-post.

[Eric Seidel (no email)]

Another example: http://www.carto.net/papers/svg/campus_dresden/index.html

[David Kilzer (:ddkilzer)]

(In reply to comment #8)
> (In reply to comment #7)
> > (From update of attachment 10004 [details] [edit] [edit])
> > Looks generally fine, but this won't compile:
> > 
> > +    return (mimeType == "image/svg+xml");
> > +         || mimeType == "image/svg-xml" // invalid, Adobe SVG Viewer
> > compatibility
> > +         || mimeType == "image/xml+svg"); // invalid, Adobe SVG Viewer
> > compatibility
> 
> What you listed does actually compile with GCC.  Maybe it won't with other
> compilers however.

I think what Darin meant was that the stray semi-colon at the end of the "return" line shouldn't be there.  He assumed that the code wouldn't compile because of it.  I fear what code was generated by gcc to compile the above, though!

[Ian 'Hixie' Hickson]

er wait, why are we doing this? The content authors will never switch to the right MIME type if we actively help them use the wrong one.

This is especially not something we should do given the W3C's recent TAG finding on the topic, wherein they said we should never ignore metadata:
   http://www.w3.org/2001/tag/doc/mime-respect-20060412

[Nikolas Zimmermann]

I agree with Ian, that we should NOT support the old broken ASV mime types.
Changing to WONTFIX.

Niko