-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi.
> Is there anything in the W3C 'file' URI Scheme Update Project that could > help us decide how to correctly parse "broken" file URLs? > http://offset.skew.org/wiki/URI/File_scheme Not directly but in http://www.faqs.org/rfcs/rfc1738.html in the section where the file URL is described one could interpret that the URL path simply has to be understood by the host where the file lies. That means if the underlying filesystem can address the file /etc/paper.config with //etc/paper.config and ////etc//////paper.config because a "//" is treated like "/./" then the following file URLs are legal, too: file:///etc/paper.config file:////etc/paper.config file://////etc//////paper.config Furthermore in the general description of the URL syntax I found this sentence: "Note that the "/" between the host (or port) and the url-path is NOT part of the url-path." (The general syntax is //<user>:<password>@<host>:<port>/<url-path>). This would mean that the URL I am having problem with (file:////home/rob/tomcat/foo.xml) is perfectly valid as its components are: "file://" + "" + "/" + "/home/rob/tomcat/foo.xml" | | | | | | | | URL path | | | | | |separator | | | host | protocol This also means that Sun's implemenation eats valid URLs for breakfast and makes them wrong (as does classpath atm). I'll fix that. cu Robert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDSQT3G9cfwmwwEtoRAiE5AJ9Vy/6QUgIfLOqfFrVHCOmUH+TOTgCfX8z9 2SL/kd6jAMoJO2x4TNgwNsg= =7N+5 -----END PGP SIGNATURE----- _______________________________________________ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
