-
Notifications
You must be signed in to change notification settings - Fork 57
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
The list of supported mime-types is too limited #28
Comments
I suggest a pull request with 3 extra mime-types. It is not at all a solution, but I am afraid the solution requires more time. The origin of the problem is MimeType enum. We cannot use enums for extendable mime-type list. But if we use other object we cannot use it in the annotation @Target(AnnotationTarget.FIELD)
annotation class StaticGet(val path: String, val mime: String, val isBinary: Boolean) But this semantics breaks the compatibility |
#28 extra mime-types are added: md, map, ttf
Well, in general the idea was to provide useful list of mime types with correct binary flags (in some cases, those flags are not really obvious). But still, we can add one more annotation that gives you ability to creates static files with custom |
I consider the annotation only from the point of compatibility. In my project I prefer KTOR version.
Concerning private val rawMimes: String
get() = """
.123,application/vnd.lotus-1-2-3
.3dmf,x-world/x-3dmf So, I see that now you are trying to make the same functionality for mime-types that has been realized in Ktor. And this leads to a code duplication. There is some other case I want to discuss. In my project I have a webpack-compiled distribution that includes files like val OctetStream = ContentType("application", "octet-stream") but Kotless just throws an Exception. And the last question concerns compatibility. I think that now the state of Kotless is experimental alpha. It has not got wide popularity, there are no projects in production with it and compatibility break will not bring a big pain to the community. |
Well, actually MimeTypes are necessary only for static resources. The main reason is that static resources are served right from S3 via API Gateway integration. Because of it Kotless should be able to understand what is the MimeType of static resource during deployment. And |
In case of |
I agree about |
I'll think about new interface for MimeTypes. Probably will create PR and will ask you to review it, if it is possible :) |
You are welcome. I will be glad to help the project |
We have a use case of building + deploying a static website folder and would like to make all the files in it available. Unfortunately any file not matching one of the expected extensions above is invalid, and fails for files like This has become one of the major pain points in building / deploying using kotless. |
Ran into this one lately, a mime-type wasn't in the list (mjs JavaScript module script), and Chrome keels over with "Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "application/octet-stream". Strict MIME type checking is enforced for module scripts per HTML spec." Is there a way to inject custom mime type mappings into what Static can handle? |
Now I see the list of supported mime-types:
And they are too few. In practice many more file types are used including ttf, md, etc. They are hundreds. So, the enum here looks inappropriate.
The text was updated successfully, but these errors were encountered: