search

w3c / svgwg

SVG Working Group specifications
Other
698 stars 132 forks source link

Request destination for SVG documents #782

Open yoavweiss opened 4 years ago

yoavweiss commented 4 years ago

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 which Sec-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.

fsoder commented 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 which Sec-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.

AmeliaBR commented 4 years ago

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.

zcorpan commented 3 years ago

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.

youennf commented 2 years ago

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.

youennf commented 2 years ago
  • Safari is using "document"

WebKit is planning to switch to "image".