Material: icon: SVG images don't load from Windows IIS web server

[willpritchard]

Actual Behavior:

• What is the issue? * Microsoft IIS 7 returns a 406 (Not acceptable) error for all SVGs used with md-icon. This seems to be caused by an inappropriate header ("Accept: application/json"), being sent by the browser when SVGs are requested using the $templateRequestservice.
• What is the expected behavior? SVGs should load without errors.

CodePen (or steps to reproduce the issue): *

• CodePen Demo which shows your issue: N/A
• Details: Host an app on IIS 7 and load it into a browser (Chrome),, check the console for the errors.

Angular Versions: *

• Angular Version: 1.5.8
• Angular Material Version: 1.1.1

Additional Information:

• Browser Type: * Chrome
• Browser Version: * 54.0.2840.99
• OS: * Windows 7
• Stack Traces:

[Robouste]

Anyone has an update on this ? 3 years later and I'm facing the same issue.
When accessing the path from the browser it works, but from angular the header is badly configured and returned a 406

[clshortfuse]

Here's the source of the issue:

https://github.com/angular/material/blob/a62d1601e352d80bf51b26f0979f724936c3d97e/src/components/icon/js/iconService.js#L654

$templateRequest needs to change the Accept parameters instead of the default application/json.

See: https://docs.angularjs.org/api/ng/provider/$templateRequestProvider#httpOptions

[Splaktar]

I wish that there was a way to do this just for the one request, without changing the $templateRequestProvider and affecting all $templateRequest calls...

@gkalpak any guidance on how we should be using these APIs?

[clshortfuse]

I noticed that too. Perhaps using $http directly.It seems the result data is cached anyway, which partially nullifies $templateRequest:

https://github.com/angular/material/blob/a62d1601e352d80bf51b26f0979f724936c3d97e/src/components/icon/js/iconService.js#L578

The only issue I see is multiple requests of the same resource would have to be throttled. That would be a little more work.

[gkalpak]

I'm afraid there is no way to do change the headers for specific requests. It seems to be an oversight that $templateRequest() uses the default Accept header for $http (application/json, text/plain, */*), but that is not going to change now :grin:

I think the best option would be to not use $templateRequest() for fetching SVG images 😞

(Also, I don't think IIS should complain, since the Accept header contains text/plain and */*, but 🤷‍♂)

[Splaktar]

Good info!

I verified that the request Accept Headers are accept: application/json, text/plain, */*.

Firebase is able to negotiate the Content Type using the */* and it responds with content-type: image/svg+xml.

This appears to be an IIS configuration issue as SVGs are not properly supported by IIS out of the box and must be configured.

It looks like the web.config file needs this addition

<configuration>
   <system.webServer>
      <staticContent>
         <mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
      </staticContent>
   </system.webServer>
</configuration>

References with a number of solutions:

• https://serverfault.com/q/359904/179110
• https://stackoverflow.com/q/12328651/633107

[clshortfuse]

Just to clarify for the users having issues, apparently IIS 7.5 doesn't include a mime type for the SVG extension. You have to add it server side. When the mime type isn't known, IIS will refer to the Content-Type as passed by the client, which is application.json. After you do set the mime type on IIS, you have to make sure your files end in .SVG or else it won't work.

It would be nice if Angular would send the right one, but it would be be a pretty hefty code change for what amounts to an edge case. (One other possible issue is if a server would send the requested SVG in a JSON, which is actually what $templateRequest is asking for. Then it wouldn't render properly when added to the DOM. As far as I know, we haven't seen that yet.)

Edit: I see Splaktar edited more info, which makes my comment a bit redundant. 😃

[Robouste]

In my case I was overriding the header in the Http Interceptor. I removed the override and left the default one and it worked