Currently, UrlResourceStream#getData determines the content-type by first calling URLConnection#getContentType. If it gets null or the string contains "unknown", it will fall back to calling Application#getMimeType (if the Application exists).
With this behavior, there is no way for the application to override the content-type detection. This causes problems when URLConnection#getContentType returns the wrong type (such as for SVG, which it deduces to be the generic "application/xml" by inspecting the first few bytes of the file, causing problems for some browsers [at least Chrome v28]). In this case, the only way to modify the content-type is to provide a new mime-types.properties file for the JDK to use.
UrlResourceStream#getData could be modified to first ask the Application for the content-type of the file, and fall back to URLConnection#getContentType if the Application isn't able to detect it. However, this may cause problems, as Application#getMimeType defaults to consulting the filename map; for cases when the content-type provided by the URL should be trusted (such as HTTP), this could lead to the wrong content-type being used if the filename doesn't match the content (such as when a .php script called over HTTP returns text/html).
Another solution could be to leave the order of operations as it is, but to call URLConnection#getHeaderField("content-type") rather than getContentType. This would avoid the defective guessing from the JDK, while allowing a URL-provided content-type to take preference. However, this might be problematic if there are subclasses of URLConnection that provide other implementations of getContentType that would be useful for those situations.
Perhaps the order of preference should be:
2. if (Application != null) Application#getMimeType
3. if (Application == null) URLConnection.getFileNameMap().getContentTypeFor
Mailing list thread where this was discussed: