Hi,
If I understand HTML <img> fetching and the fetch spec right. The default
behavior on image fetching is No CORS with the mode tainted cross-origin.
For the example: <img src="image.svg">
and image.svg:
<svg>
<image xlink:href="http://otherdomain.com/image.svg";>
</svg>
In this case the image.svg would be fetched with basic fetch and tainted
cross-origin. But the image inside this image would also be loaded as basic
fetch tainted cross origin. Right?
For various reasons (as described in Mozilla bug 628747[1]). We do not want to
have image load further _external_ resources.
WebKit, Blink and Gecko allow dataURLs and Gecko allows blobs as resources. I
couldn't find a specification for that in the Fetch specification. WebKit and
Blink call that "single security origin". If the SVG was fetched as an image
resource, it is not allowed to fetch other resources with the described
exception above.
So, I wonder how that behavior could be described. Sadly it is not always the
same behavior. If the SVG image is referenced by an <object>, <embed> or
<iframe>, it does not count as "image" anymore but as a document and it can
fetch resources again. For my use case of <mask> and <filter> the SVG WG
resolved to have the same fetching mechanisms and restrictions as for SVG as
"images".
To summarize. We have two kind of possibilities of fetching in SVG:
SVG with "single security origin": The SVG is not allowed to fetch any external
resources. References in the same document and dataURLs, blobs are allowed.
SVG "as document": Allowed to fetch resources with No CORS - But: possibly CORS
enabled depending on the referencing element (<object>, <embed> or <iframe>).
Would it be possible to define it that way? If the former named elements, then
use the fetching mechanism defined by these elements. Otherwise use "single
security origin"? Could Fetch define "single security origin"?
Greetings,
Dirk
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=628747
![http://otherdomain.com/image.svg"](http://otherdomain.com/image.svg"){kind=link}