-
-
Notifications
You must be signed in to change notification settings - Fork 319
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
mime.getExtensions('text/xml') is null #180
Comments
Hmm... good point. The goal here was to eliminate the ambiguity around the more common problem of resolving an extension to a mime-type. Breaking the ability to map less-preferred types to an extension was an unintentional side-effect of that. Any chance you'd be willing to put together a PR? I think it would be okay to keep these sorts of mappings, as long as the extension -> type mapping always resolves to the highest scoring type (per the |
@broofa I don't see a way to do that without breaking the format of {
"types": {
"application/xml": ["xml"],
"text/xml": ["xml"]
},
"extensions": {
"xml": ["application/xml", "text/xml"]
}
} Also what do you think of adding |
@valeriangalliat 'Been thinking about this and the least impactful solution I can come up with is to change the build step such that, instead of filtering out the conflicting extensions, it prefixes the non-default extensions with a
Then have the [Edit: Regarding adding |
Amazing, thank you! |
Version 2.0.3.
types/standard.json
have"text/xml":[]
.This is caused by this line.
I understand the idea of preferring
application/...
types overtext/...
but is it the expected behaviour that we can't reverse the proper extension from let's saytext/xml
becauseapplication/xml
also exists?Thank you!
The text was updated successfully, but these errors were encountered: