[
https://issues.apache.org/jira/browse/WICKET-6757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17062905#comment-17062905
]
ASF subversion and git services commented on WICKET-6757:
---------------------------------------------------------
Commit f1bd38690674be5578fc5c5e1c28cc81cdb7ae76 in wicket's branch
refs/heads/master from Thorsten Schöning
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=f1bd386 ]
WICKET-6757 Avoid URL.getFile() for mime type detection
Mime type detection is documented to work on paths or URLs, but
URL.getFile provides neither of both and the default implementation is
very limited regarding / vs. \ and such things. Forwarding an absolute
URI always instead is compatible with the default implementation and
makes absolutely clear what is available. URL.getFile for example might
look like some path in the file system, but would work with paths
containing spaces because of no decoding.
> Avoid URL.getFile during mime type detection.
> ---------------------------------------------
>
> Key: WICKET-6757
> URL: https://issues.apache.org/jira/browse/WICKET-6757
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 8.7.0
> Reporter: Thorsten Schöning
> Priority: Minor
>
> This is a special case of
> [WICKET-6756|https://issues.apache.org/jira/projects/WICKET/issues/WICKET-6756]:
> "URL.getFile" shouldn't be used when expecting paths, because it [doesn't
> properly
> decode|https://stackoverflow.com/questions/2166039/java-how-to-get-a-file-from-an-escaped-url]
> e.g. spaces in components. Wicket provides an individual [mime type
> detection|https://ci.apache.org/projects/wicket/apidocs/8.x/org/apache/wicket/Application.html#getMimeType-java.lang.String-]
> per Application, which is documented to work on "file names" and in the
> default implementation simply [forwards to what Java
> provides|https://docs.oracle.com/javase/8/docs/api/java/net/FileNameMap.html#getContentTypeFor-java.lang.String-]
> itself already.
> While that is documented to work on file names and URLs as well, the default
> implementation
> [sun.net.www.MimeTable|https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/share/classes/sun/net/www/MimeTable.java#L169]
> is very limited regarding path separators and doesn't decode individual
> parts of URL at all. It simply works on strings containing slashes and makes
> it somewhat unreliable if someone really provides e.g. a Windows-path. OTOH,
> forwarding "URL.getFile" looks like a file system path is given and because
> that is documented in theory, one might want to use a given path to actually
> look in the header of files to get their mime type and that breaks again if
> e.g. a path with spaces is forwarded, because that is not properly decoded.
> So my suggestion is to simply forward an absolute URI itself always, because
> that can't be misinterpreted: It is compatible with the default
> implementation of Java expecting strings with slashes only and in case of a
> file-URI, custom implementations can easily recognize that and decide to
> parse it as file system path with properly decoding things like encoded
> spaces. This simply makes the interface and implementation of Wicket itself
> more robust in the end and removes a not-so-robust "URL.getFile".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
