Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
8.7.0
-
None
Description
This is a special case of WICKET-6756: "URL.getFile" shouldn't be used when expecting paths, because it doesn't properly decode e.g. spaces in components. Wicket provides an individual mime type detection per Application, which is documented to work on "file names" and in the default implementation simply forwards to what Java provides itself already.
While that is documented to work on file names and URLs as well, the default implementation sun.net.www.MimeTable 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".
Attachments
Issue Links
- links to