support for sniffing image SVG

[odeke-em]

I kindly would like to ask if it is possible for us to add support for sniffing SVG images. If the signature is added here, it will allow adding the signature to the Go standard library and potentially other consumers that depend on the standards here. My motivation is to solve this issue golang/go#15888, if the signature is present.
Currently the *NIX utility file supports it and I can even copy just 512 bytes of an SVG file where the original is https://upload.wikimedia.org/wikipedia/commons/f/f1/Android_sample.svg

$ file Android_sample.svg 
Android_sample.svg: SVG Scalable Vector Graphics image
$ ls -lh Android_sample.svg
-rw-r--r--  1 emmanuelodeke  staff    11K  6 Oct  2013 Android_sample.svg
$ dd if=Android_sample.svg of=first512 bs=512 count=1
$ file first512 
first512: SVG Scalable Vector Graphics image
$ ls -lh first512 
-rw-r--r--  1 emmanuelodeke  staff   512B 29 May 20:42 first512

Please let me know how I can be of help in getting this solved.
Thank you.

[annevk]

I think we would rather not add sniffing for XML. The way SVG images work is by properly labeling them as image/svg+xml. The code path that loads images then first checks for that and only if that is missing starts sniffing for (other) images.

[masinter]

the "bug" doesn't ask for sniffing in general, it asks for sniffing at file upload, where you might pay attention to the .svg file extension too.

[odeke-em]

@annevk alright. I could look at the way file sniffs svg. However, for that signature to be added to Go, it needs the whatwg mimesniff spec blessing, that's why I filed the bug here.

"the "bug" doesn't ask for sniffing in general, it asks for sniffing at file upload, where you might 
pay attention to the .svg file extension too."

@masinter actually that ability is used in net/http/sniff DetectContentType and its purpose is to determine the content-Type from sniffing 512 bytes of data. It used in servers internally when serving back content, sniff the type and appropriately set the "Content-Type" header if not already set in the response. The data served back usually won't have an extension since it is just an http response payload. I happen to be the last person that touched that code and would like to see if we could support it.
Also at my day job, we rely on DetectContentType in Go, for purposes of categorizing content read from raw bodies in the wild, so implementing it is something I am interested in. We fall back to exec-ing to file as an alternative but if it could be in Go, that'd be pleasant.

[annevk]

Is file extension the only way to determine a MIME type when uploading or some such? What do browsers do there today?

[annevk]

See also w3c/FileAPI#51.

[annevk]

I'm closing this. That File API issue is the place to standardize local file system mappings. And we don't want to introduce more sniffing for this case. Please label the SVG resources instead somehow.

[annevk]

To not close the door here entirely I filed #51 to sort out the exact scope of this document as there seems to be some tension between the requirements of Go and that of a browser. It would be good to resolve such conflicts or at least clearly document them.

[benkasminbullock]

This is a nuisance problem when serving SVG images via a Go http server, the mime type has to be adjusted to image/svg+xml manually or the image won't display.