Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we sniff content? #18

Open
lpar opened this issue Jul 11, 2020 · 1 comment
Open

Should we sniff content? #18

lpar opened this issue Jul 11, 2020 · 1 comment

Comments

@lpar
Copy link
Owner

lpar commented Jul 11, 2020

Turning part of #16 into a standalone item.

In case the mime type cannot be determined from the extension by the mime.TypeByExtension method, ServeContent will try to infer from the actual file content: https://golang.org/src/net/http/fs.go?s=4932:5036#L198 so it will return a type like "application/x-gzip", whereas http.FileServer would have return "text/plain" for a YAML file, for example. This can lead to bugs, for example when trying to use the Swagger UI.
=> workaround: register such non-standard types (there's actually no official mime type for YAML):
mime.AddExtensionType(".yaml", "application/x-yaml")

I'm not a big fan of content sniffing, as it can lead to really obscure bugs. However, it wouldn't be all that hard to read a chunk from the uncompressed version of the file, and call http.DetectContentType to pick a MIME type.

@stokito
Copy link

stokito commented Feb 22, 2023

I just had a problem that mime type wasn't detected by a file extension but was sniffed instead.
This is a well known problem for the golang http package and you can't do anything about it.
I solved the problem myself by registering a mime type of the file extension:

_ = mime.AddExtensionType(".ndjson", "application/x-ndjson")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants