[jira] [Resolved] (WICKET-5295) UrlResourceStream#getData content-type detection relies on flawed logic in URLConnection#getContentType

["Martin Grigorov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov resolved WICKET-5295.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 6.10.0
                   7.0.0
    
> UrlResourceStream#getData content-type detection relies on flawed logic in URLConnection#getContentType
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-5295
>                 URL: https://issues.apache.org/jira/browse/WICKET-5295
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 6.9.1
>            Reporter: Chris Snyder
>            Assignee: Martin Grigorov
>            Priority: Minor
>             Fix For: 7.0.0, 6.10.0
>
>
> 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:
> 1. URLConnnection#getHeaderField("content-type")
> 2. if (Application != null) Application#getMimeType
> 3. if (Application == null) URLConnection.getFileNameMap().getContentTypeFor
> 4. URLConnection#getContentType
> Mailing list thread where this was discussed:
> http://mail-archives.apache.org/mod_mbox/wicket-users/201307.mbox/%3C29C80C91-4618-4E96-991F-998D571957AA%40biologos.org%3E

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira