[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: URLStreamHandler.parseURL()
From: |
Mohan Embar |
Subject: |
Re: URLStreamHandler.parseURL() |
Date: |
Mon, 05 Jul 2004 18:21:12 -0500 |
Hi Jeroen,
>> You have removed this block:
>>
>> -if (lastSlash < 0 && File.separatorChar != sepChar
>> - && url.getProtocol().equals("file"))
>> - {
>> - // On Windows, even '\' is allowed in a "file" URL.
>> - sepChar = File.separatorChar;
>> - lastSlash = file.lastIndexOf(sepChar);
>> - }
>>
>> ...and have replaced it with this:
>>
>> +int lastSlash = file.lastIndexOf('/');
>>
>> ...but nowhere in your patch have you changed the
>> original contents of the file variable, which contains
>> this backslash.
>
>Thanks, I see what you mean now. I still disagree with it though ;-)
>AFAIK, on Windows a '\' is not valid in a url, so URL.getFile() should
>always return a '/' separated path. If it doesn't do that, then this
>should be fixed, but I don't think the problem is here.
I agree that the specifications are confusing. If you look at RFC 2396,
which the JavaDoc for java.net.URL references:
http://www.ietf.org/rfc/rfc2396.txt
...you see that "\" isn't part of standard URI notation, but they do say
that "URI that do not make use of the slash "/" character for separating
hierarchical components are considered opaque by the generic URI
parser."
The reason that we're getting URL's with backslashes stems from
this code in gnu.gcj.runtime.VMClassLoader:
-----------------------------------------------------------------------------------------------
StringTokenizer st
= new StringTokenizer (System.getProperty ("java.class.path", "."),
System.getProperty ("path.separator", ":"));
while (st.hasMoreElements ())
{
String e = st.nextToken ();
try
{
if (!e.endsWith (File.separator) && new File (e).isDirectory ())
addURL(new URL("file", "", -1, e + File.separator));
else
addURL(new URL("file", "", -1, e));
}
catch (java.net.MalformedURLException x)
{
/* Ignore this path element */
}
}
-----------------------------------------------------------------------------------------------
We're using URL.URL(String, String, int, String). Sun's JavaDoc says that
no validation of inputs is performed for this constructor.
Now let's look at what Sun's JRE does in practice. I ran the following
sample on Sun's 1.4.1_01 on Win32:
-----------------------------------------------------------------------------------------------
import java.io.*;
import java.net.URL;
public class WinURL
{
public static void main(String[] args)
{
try
{
URL url =
new URL
(
"file",
"",
-1,
"l:\\gcc\\examples\\WinURL\\hello.txt"
);
System.out.println("url.getFile(): "+url.getFile());
InputStream istr = url.openStream();
BufferedReader rdr =
new BufferedReader(new InputStreamReader(istr));
String strLine;
while ((strLine = rdr.readLine()) != null)
System.out.println(strLine);
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
-----------------------------------------------------------------------------------------------
This is the output I got:
-----------------------------------------------------------------------------------------------
url.getFile(): l:\gcc\examples\WinURL\hello.txt
Hello, world.
Pleased to meet you.
-----------------------------------------------------------------------------------------------
(gcj's output on Win32 is identical.)
So it appears that backslashes in URLs are permissible under
Sun's JRE on Win32 and that moreover, URL.getFile() can also
return strings which contain backslashes.
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/