SVG files delivered with proper MIME type by static.py

[wthie]

Fixes #88.

[wthie]

Sorry if this is not properly tacked to issue #88, I tried to fumble my way around doing a pull request. Is there a canonical way to do this?
I'm running my fork and just did this simple patch on origin:master, but I guess I should have made a branch first and then do the pull request from the branch. What would be the proper name of the branch? Thanks for enlightening me!

[mithrandi]

To link the PR to the issue, you want something like "Fixes #nn" in the PR description (I've edited it for you). The branch name is basically unimportant, I would usually use something like "88-svg-mime-type" in this case. A PR from master like this is fine if you don't have other changes, though :)

[mithrandi]

I'm a little curious, does your /etc/mime.types not have .svg in it, or do you not have a /etc/mime.types? (This patch seems reasonable notwithstanding my query, given how common SVG is on the web)

[wthie]

Thanks for the clarification, I'll try to follow your words.
I just ran into the problem while developing on OSX, which definitely does not have a mime.types file. SVG's were displayed ok in FF until recently after an FF upgrade they were suppressed, I guess this was a security fix coming from Mozilla. The FreeBSD machine I use to test deploy is still running FreeBSD 8.4 (I know I should upgrade...) and also does not have such a file as /etc/mime.types. This situation eventually forced me add the svg mime type to the basic add on list in nevow.

[mithrandi]

It seems FreeBSD shipes a MIME types file in the misc/mime-support port; the file is shipped at /usr/local/etc/mime.types which will not be read directly by Nevow, however the mimetypes module should find it. On OS X, it doesn't look like the OS ships MIME types in a reliable location (there's various copies floating around, but reading from, say, /private/etc/apache2/mime.types or /usr/share/cups/mime/mime.types seems like a bad idea). shared-mime-info from Homebrew could be used, but this path is not searched by the mimetypes module, so I guess that doesn't help.