[Webkit-unassigned] [Bug 201295] [Gtk] Inline SVG confuses local file parsing

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=201295

--- Comment #6 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Alexey Proskuryakov from comment #5)
> > This is a local file (file:///) so I don’t “being served with” makes much sense here.
> 
> Thank you for the clarification.
> 
> Making the file valid HTML would almost certainly fix the symptom (i.e.
> remove the spurious slash at the end of <link>, xmlns and version attributes
> on <svg>, and anything else the HTML5 validator points out).

I tried those tweaks but didn't notice any difference.

The content sniffer isn't nearly that sophisticated anyway. I think it's rather more simple: the content sniffer, shared-mime-info, sees <svg> in the file and that wins because it has a higher "magic priority" used to determine the content type. It won't be fixed without a bug report to https://gitlab.freedesktop.org/xdg/shared-mime-info/issues

Normally I'd close the issue here as not WebKit's fault, but:

> > Alexey, could you check if it works in Safari?
> 
> Our stack doesn't do any content sniffing, the extension is all that matters
> for local files. Given how many malformed XML documents exist out there,
> only working because they are parsed as HTML, I suggest dropping content
> sniffing in other ports as well.

OK, soup ports should stop content sniffing then.

It looks like I may have enabled use of SoupContentSniffer accidentally in r238805. Per the SoupSession documentation: "Additionally, sessions using the plain SoupSession class (rather than one of its deprecated subtypes) have a SoupContentDecoder by default." I'm not sure what actual impact that has, though, because WebKit doesn't intentionally use that functionality anywhere. And we've definitely done some form of content type sniffing long before this, because I remember a much older bug where shared-mime-info misidentified XHTML vs. HTML, causing breakage. I'm not sure where WebKit actually uses shared-mime-info, though. It's probably done via GIO somewhere.

The SoupContentSniffer documentation also says: "SoupContentSniffer provides support for HTML5-style response body content sniffing." I'm not sure what it means by that ("HTML5-style"), but it's clear somebody thought about it and decided this was desirable to do.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190906/a46b9850/attachment.html>