Re: URLStreamHandler.parseURL()

[Mohan Embar <gnustuff at thisiscool dot com>]

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/