Hi,
*Observation:*
On Unix and Windows respectively, the following code runs fine:
Unix:
jshell> new URL("file://localhost/etc/hosts").openStream();
$8 ==> java.io.BufferedInputStream@59f95c5d
Windows:
jshell> new
java.net.URL("file://localhost/C:/Windows/System32/drivers/etc/hosts").openStream()
$13 ==> java.io.BufferedInputStream@33e5ccce
However, when we add a query parameter to the URL, the picture changes:
Unix:
jshell> new URL("file://localhost/etc/hosts?name=value").openStream();
$9 ==> java.io.BufferedInputStream@4aa8f0b4
Windows:
jshell> new
java.net.URL("file://localhost/C:/Windows/System32/drivers/etc/hosts?name=value").openStream()
| Exception java.io.FileNotFoundException:
C:\Windows\System32\drivers\etc\hosts?name=value (The filename, directory
name, or volume label syntax is incorrect)
| at FileInputStream.open0 (Native Method)
| at FileInputStream.open (FileInputStream.java:185)
| at FileInputStream.<init> (FileInputStream.java:139)
| at FileInputStream.<init> (FileInputStream.java:109)
| at FileURLConnection.connect (FileURLConnection.java:83)
| at FileURLConnection.getInputStream (FileURLConnection.java:185)
| at URL.openStream (URL.java:1260)
| at (#14:1)
*Analysis:*
Looking at the Windows implementation of sun.net.protocol.www.file.Handler,
it indeed uses URL::getFile when constructing the file path, while the unix
implementation uses URL::getPath.
Unlike the generic URI syntax described in RFC 3986, the file URI RFC 8082
does not include a query component in its syntax description.
This leaves the implementor the choice of ignoring query components (like
we do for Unix) or rejecting the URL (which we effectively, while not
explicitly, do for Windows).
*Action:*
I think it would make sense to align our implementations here. If we choose
to do so, I think it would make most sense to adjust the Windows
implementation to also ignore the query component by using URL::getPath
instead of URL::getFile, like we currently do for Unix.
Thoughts?
Eirik.
