Open yoavweiss opened 4 years ago
It's unclear which request destination fetched SVG document should have, which can impact which CSP directives control them, which
as
values developers need to set in order to preload them and whichSec-Fetch-Dest
headers servers see in their requests.
Well, it's unclear because no one on the "fetch side" knew about them presumably (and didn't spend any time finding out).
Furthermore, current implementations are use different destinations in different contexts. For example, Chrome seems to use "document" when fetching the SVG document into its own browsing context,
That seems about right since that would just be a regular "navigate" case.
but uses the "image" destination when the document is fetched using a
<use>
element.
Since these documents are often referred to (at least by some... and the spec section you linked) as "(sub)resource documents" and they are supposed to be in "secure static mode" (meaning no scripting for example) maybe they should be "resource-document"
or "static-document"
or something like that.
I don't know much about the options in the fetch spec (and don't have time to research right now), but I do agree that it is likely appropriate to have different headers according to the different contexts in which the SVG will be loaded, since the SVG spec does expect different security models for them.
See https://github.com/web-platform-tests/wpt/pull/25247#issuecomment-762755868 , the test fetch/metadata/generated/svg-image.https.sub.html
tries to verify Fetch Metadata headers (sec-fetch-dest
) for SVG image
requests. The lack of Fetch integration makes it hard to know what to test.
uses the "image" destination when the document is fetched using a
<use>
element.
<use>
element destination seems all over the place:
"document" is probably wrong since this triggers service worker registration matching while we should probably use the embedding document service worker registration.
- Safari is using "document"
WebKit is planning to switch to "image".
Relevant spec section: https://svgwg.org/svg2-draft/linking.html#processingURL-fetch Related Fetch spec issue: https://github.com/whatwg/fetch/issues/1012
It's unclear which request destination fetched SVG document should have, which can impact which CSP directives control them, which
as
values developers need to set in order to preload them and whichSec-Fetch-Dest
headers servers see in their requests.Furthermore, current implementations are use different destinations in different contexts. For example, Chrome seems to use "document" when fetching the SVG document into its own browsing context, but uses the "image" destination when the document is fetched using a
<use>
element.