To correctly render ANY content, including .SVG, requires:
1. Web Server to send correct Content-Type: for the resource
2. Web Browser to have correct plugin to process that Content-Type
By default, Web Servers send pre-configured Content-Type for things
like .html, .xml, .jpg, etc and Web Browsers have default plugins pre-
configured to process those Content-Types, so things all "magically"
work.
Unfortunately, this pre-defined "magic" lulls users into thinking they
can just dump any content onto the server, the server will figure out
what to do with it, and the client will magically figure out how to
render it. And so they think it is a problem with the server when they
dump .SVG contents onto the server and it does not render.
Hardly realistic expectation on "magic", but wait, the browsers did
something even more ridiculous. The browsers wager that since
webmastering users running websites are too clueless to correctly set
Content-Type (or they forget, which is often the case), the browser
should use "sniffing" techniques to correctly determine "popular"
content webmastering users want to set as download. This then irked
the competent users who wish to mis-match content with Content-Type to
change browser handling (for example, handling of compressed resources
to either open or save, or to auto-launch downloads, another sneaky
behavior), and you end up with a whole big jungle of download vs
execute compatibility "issues" on the client. And this is why you see
IE with options like "Open files based on content, not extension". But
maybe we don't want to be so hard on the IE team since it was not
completely their fault. Remember Netscape Navigator? In the
marketshare competition over a decade!!! ago, it became necessary to
do such "best effort" rendering of otherwise broken HTTP responses.
And IE the underdog at that time had to match bug-for-bug
"compatibility" with Navigator...
Lesson: Competition is a good thing, but not when it bends standards.
It just ends up with support nightmare for the eventual winner/
participants.
Ranting aside... To have .SVG process correctly, you need to:
1. Configure MIME Type on IIS for .SVG to send the correct Content-
Type. By default, if you change the MIME Type on a web-site level it
automatically takes effect, while if you change the global MIME Type
it requires restarting IIS to take effect. This can be easily verified
by making a simple HTTP request to the web server for a resource
with .SVG extension and checking the value of the Content-Type
response header.
2. Configure Browser to run plugin to process .SVG extension. You've
noted that FireFox comes with some built-in plugin to handle it. You
need to make sure IE has similar plugin if you expect it to render
there.
If you've done both these things and verified that IIS is sending the
correct Content-Type for .SVG, then the issue cannot be with IIS core
since it just does download of that content. The issue will likely be
with 3rd party software on IIS to process .SVG (possibly?), additional
proprietary configuration for SVG required on IIS (non-RFC standard
configuration), networking device between server/client, or plugin
configuration on the client.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
On Sep 16, 3:13 pm, "~~~ .NET Ed ~~~" <tiredofs... DeleteThis @abolishspam.now>
wrote:
> The response of the "good" page has Mime type image/svg+xml which is the
> exact MIME type I added in the IIS management console.
>
> "Daniel Crichton" <msn... DeleteThis @worldofspack.com> wrote in message
>
> news:uRAhCXt9HHA.3548@TK2MSFTNGP06.phx.gbl...
>
>
>
> > ~~~ wrote on Fri, 14 Sep 2007 09:20:58 +0200:
>
> >> I have a puzzling problem. When I use FireFox to browse a page that has
> >> Scalable Vector Graphics items (.SVG) then these SVG items are rendered
> >> on the page inline. My FF comes with a built in Adobe pluggin or
> >> something like that.
>
> >> The problem is, when I create a page on my local webserver (XP Pro SP2
> >> with IIS 5.1) and try to browse the page, rather than seeing the SVG
> >> content
> >> inline I get a dialog asking me what to do with the .SVG file (Dowload,
> >> etc.) which is not the intended behaviour. Specially considering that
> >> the browser IS capable of processing such content.
>
> >> At first I realized that my virtual directory did not have a MIME entry
> >> for this type. I went to the IIS administrator console and added the
> >> image/svg+xml MIME type for the .SVG extension. This I added for both
> >> my virtual directory and the root site. Then I restarted IIS.
>
> >> Unfortunately that does not seem to have done anything at all, when I
> >> fetch the page it still asks me what to do with the .SVG file
>
> >> Any ideas? is IIS 5.1 uncapable of handing this? I think it would be
> >> rather odd if I also had to add a file association on my XP machine to
> >> associate .svg with some sort of application. And if that was so, then
> >> which application? I mean it could be FireFox or IE or God knows what
> >> but I wonder if that is correct. At least that is not what I expect
> >> the problem to be.
>
> >> Thanks in advance,
>
> >> Emilio
>
> > The Save As handling is a browser issue, not server. It may however be
> > mitigated by an incorrect MIME header - with the page that works you
> > mentioned at the start, inspect the HTTP headers to see what that server
> > is returning. Compare it to what yours is. Adjust yours to match the other
> > server.
>
> > Dan- Hide quoted text -
>
> - Show quoted text - >> Stay informed about: IIS 5.1 not working with .SVG documents