Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 470601 SVG <use> element blocking cross-domain requests, with no option to use CORS
Starred by 22 users Reported by joel@fullstory.com, Mar 25 2015 Back to list
Status: Assigned
Owner:
Cc:
Components:
NextAction: ----
OS: All
Pri: 2
Type: Bug


Sign in to add a comment
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Create a page on `a.com` with SVG such as the following:

    <svg>
      <use xlink:href="https://b.com/some.svg#some-id"></use>
    </svg>

2. Place `some.svg` on b.com, with response header:

    Access-Control-Allow-Origin: *

What is the expected behavior?
The SVG <use> reference renders the SVG fetched from `b.com`.

What went wrong?
"Unsafe attempt to load URL https://b.com/some.svg from frame with URL https://a.com/some.html. Domains, protocols and ports must match."

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? No Firefox, Safari tip

Chrome version: 41.0.2272.89  Channel: stable
OS Version: OS X 10.10.2
Flash Version: Shockwave Flash 17.0 r0

It's not really clear from the spec (e.g., http://www.w3.org/TR/SVG/linking.html) that there's any reason for this not to work. It does make sense that this request would be blocked without CORS headers (even though it's not clearly specified), but I would at least expect it to try CORS before simply blocking the request.
 
Cc: brajkumar@chromium.org
Labels: Needs-Feedback
joel@ -  Could you please provide sample html file where we can look in to this issue for further assistance.
Comment 2 by e...@opera.com, Mar 26 2015
Cc: mkwst@chromium.org
Content Security Policy (CSP) may prevent loading such resources.

@mkwst: are there any tests for this particular scenario in blink?
Comment 3 by joel@fullstory.com, Mar 26 2015
@brajku: Kind of. It's not simple to provide a full reproduction, because doing so (at least relative to the way I've reported it) requires controlling HTTP response headers to test the CORS case.

I've created the following example, which gets you 90% of the way there. To test it with CORS, you'll need to take `svg.svg` and run it in your own HTTP server on another domain, with `Access-Control-Allow-Origin: *` in the response.

http://plnkr.co/edit/SC1Mgd79nb1LS4mr31Nq?p=preview


@e: That's what I would expect. It's hard to be sure from the spec (afaict, CSP/CORS don't get discussed much, if at all, in specs like svg and xlink), but I was under the impression that vendors were generally trying to use CORS as a standard workaround for CSP-related issues.

Comment 4 by mkwst@chromium.org, Mar 26 2015
Cc: pdr@chromium.org
Labels: Cr-Blink-SVG
That's not a CSP issue, that's the "access denied" message you'd get if you couldn't request the resource. Adding pdr@ for some SVG expertise.
Comment 5 by pdr@chromium.org, Mar 26 2015
Cc: tabatkins@chromium.org e...@opera.com
Labels: -Needs-Feedback
Status: Available
@Joel, you're way ahead of implementations here, and probably specs too. I agree that this is a bug and we should fix it as you've described by having CORS apply to SVG's xlink references. We don't have any tests or code for this today.

A workaround today is to use a preprocess step to bundle external requests into a single file.

@ed, would you like to investigate this area? http://crbug.com/234082 is another example but for CSP. As far as I'm aware, this is uncharted territory.
Comment 6 by e...@opera.com, Mar 27 2015
Owner: e...@opera.com
Status: Assigned
I'll take a look.
Comment 7 by e...@opera.com, Mar 27 2015
Right now all* browsers block <use> from loading anything cross-origin.

My suggestion is to add a 'crossorigin' attribute on <use>. I can propose this to the SVG WG, assuming we all agree that we should allow opting in to using CORS here.

Draft CL: https://codereview.chromium.org/1036323002

* Tested in Firefox Nightly, IE11 and Opera/Chrome dev.
Comment 8 by joel@fullstory.com, Apr 15 2015
@e...: That sounds perfect for our purposes, and matches the CORS pattern used elsewhere, so I'm quite supportive. Let me know if you need any support on the mailing list from people with software affected by this.
Comment 9 by e...@opera.com, Apr 16 2015
I've put it on the SVG WG agenda, but we've not yet had an opportunity to discuss it. Anyway, the thread is here: https://lists.w3.org/Archives/Public/www-svg/2015Mar/0139.html
Comment 10 by e...@opera.com, May 8 2015
Labels: -OS-Mac OS-All
Owner: f...@opera.com
Handing this over.
Comment 11 by tkent@chromium.org, Jul 10 2015
Labels: -Cr-Content Cr-Blink
Comment 12 by tkent@chromium.org, Oct 16 2015
Labels: -Cr-Blink
Is there any movement on this issue? It's crippling our attempt to host SVG packs on our CDN and load them in cross domain using <use xlink:>. 
Comment 14 by f...@opera.com, Feb 25 2016
It's currently blocked on "spec issues" I'm afraid:

https://www.w3.org/Graphics/SVG/WG/track/actions/3781 (see the "Blocked on"-link for further context.)
Is there a way or hack to go around this issue?

Until the spec is finalized, that is?
Comment 16 by f...@opera.com, Mar 17 2016
I'm afraid not. (Well, not client-side at least - if so that'd be a bug...)

Maybe somewhat tongue-in-cheek, but I think the best you can do is make more noise about it (just not here =))
Comment 17 by gheto...@gmail.com, Apr 24 2016
no perfect solution but a temporary workaround would be to ajax the svg and inject it into the DOM. That way you just need to manage ajax CORS.
Also it adds the benefits to work with ie and css rules on shapes.
Source: https://css-tricks.com/ajaxing-svg-sprite/

We shouldn't expect any official/clean way to do that until some years....
Cc: -e...@opera.com
Sign in to add a comment