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

mime.getExtensions('text/xml') is null #180

Closed
valeriangalliat opened this issue Nov 13, 2017 · 4 comments
Closed

mime.getExtensions('text/xml') is null #180

valeriangalliat opened this issue Nov 13, 2017 · 4 comments

Comments

@valeriangalliat
Copy link

Version 2.0.3.

types/standard.json have "text/xml":[].

This is caused by this line.

I understand the idea of preferring application/... types over text/... but is it the expected behaviour that we can't reverse the proper extension from let's say text/xml because application/xml also exists?

Thank you!

@broofa
Copy link
Owner

broofa commented Nov 14, 2017

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 getScore() method).

@valeriangalliat
Copy link
Author

valeriangalliat commented Nov 14, 2017

@broofa I don't see a way to do that without breaking the format of typeMap, do you think typeMap could have the following schema?

{
  "types": {
    "application/xml": ["xml"],
    "text/xml": ["xml"]
  },
  "extensions": {
    "xml": ["application/xml", "text/xml"]
  }
}

Also what do you think of adding getTypes and getExtensions methods that would return an array of matching types or matching extensions (in priority order)?

@broofa
Copy link
Owner

broofa commented Nov 25, 2017

@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 * (or other appropriate character). E.g.

{
  ...
  "application/xml": ["xml"],
  "text/xml": ["*xml"],
  ...
}

Then have the Mime class treat the non-default entries appropriately in the define() method. It's a bit of a hack, but it'd be backward compatible with the current code.

[Edit: Regarding adding getTypes and getExtensions, I'd rather not. I don't think there's enough value there. I'm content for the time being telling anyone needing such functionality to just code their own solution using the mime-db module.]

@broofa broofa closed this as completed in b5c83fb Jan 4, 2018
@valeriangalliat
Copy link
Author

Amazing, thank you!

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

No branches or pull requests

2 participants