You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@xalan.apache.org by cu...@apache.org on 2002/01/13 22:25:06 UTC
cvs commit: xml-xalan/java/src/org/apache/xml/utils SystemIDResolver.java
curcuru 02/01/13 13:25:06
Modified: java/src/org/apache/xml/utils SystemIDResolver.java
Log:
Fix Bugzilla#5701: incorrect resolution of certain kinds of absolute file: URIs
Note: This definitely seems to be more correct in terms of resolving URIs
vis-a-vis RFC 2396 than it used to be. The only user case which might now
fail where it used to work is a user that supplies an incorrect
'file:subdir/blah' that they intended to be a relative URI (technically
it is an absolute URI no matter which way you look at it); this might
lead to a change in behavior in this particular case, although the behavior
before was incorrect.
The major risk factor could be if there are other parts of Xalan code that rely
on the previously incorrect behavior, but I can't find any, and the whole test
suite runs and passes normally.
Revision Changes Path
1.14 +52 -10 xml-xalan/java/src/org/apache/xml/utils/SystemIDResolver.java
Index: SystemIDResolver.java
===================================================================
RCS file: /home/cvs/xml-xalan/java/src/org/apache/xml/utils/SystemIDResolver.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- SystemIDResolver.java 11 Oct 2001 15:49:58 -0000 1.13
+++ SystemIDResolver.java 13 Jan 2002 21:25:06 -0000 1.14
@@ -69,14 +69,22 @@
* <meta name="usage" content="internal"/>
* This class is used to resolve relative URIs and SystemID
* strings into absolute URIs.
+ *
+ * <p>This is a generic utility for resolving URIs, other than the
+ * fact that it's declared to throw TransformerException. Please
+ * see code comments for details on how resolution is performed.</p>
*/
public class SystemIDResolver
{
/**
* Get absolute URI from a given relative URI.
- * The URI is resolved relative to the system property "user.dir"
- *
+ *
+ * <p>The URI is resolved relative to the system property "user.dir"
+ * if it is available; if not (i.e. in an Applet perhaps which
+ * throws SecurityException) then it is currently resolved
+ * relative to "" or a blank string. Also replaces all
+ * backslashes with forward slashes.</p>
*
* @param uri Relative URI to resolve
*
@@ -99,7 +107,12 @@
base = "file://" + curdir;
else
base = "file:///" + curdir;
+
if (uri != null)
+ // Note: this should arguably stick in a '/' forward
+ // slash character instead of the file separator,
+ // since we're effectively assuming it's a hierarchical
+ // URI and adding in the abs_path separator -sc
uri = base + System.getProperty("file.separator") + uri;
else
uri = base + System.getProperty("file.separator");
@@ -124,16 +137,32 @@
{
if (url.startsWith(".."))
url = new File(url).getAbsolutePath();
+
if (url.startsWith(File.separator))
+ {
+ // If the url starts with a path separator, we assume it's
+ // a reference to a file: scheme (why do we do this? -sc)
url = "file://" + url;
+ }
else if (url.indexOf(':') < 0)
{
+ // If the url does not have a colon: character (which
+ // separates the scheme part from the rest) then it
+ // must be a relative one, so go get an absolute one -sc
url = getAbsoluteURIFromRelative(url);
}
- else if (url.startsWith("file:") && url.charAt(5) != '/')
- {
- url = getAbsoluteURIFromRelative(url.substring(5));
- }
+
+ // Bugzilla#5701: the below else if is incorrect, if you read
+ // section 5.2 of RFC 2396. If the url did start with file:,
+ // it implies we should assume it's absolute and be done
+ // with resolving. Note that I'm not even sure why we put
+ // in the second check for '/' anyways -sc
+ //else if (url.startsWith("file:") && url.charAt(5) != '/')
+ //{
+ // url = getAbsoluteURIFromRelative(url.substring(5));
+ //}
+ // Bugzilla#5701 comment out code end
+
return url;
}
@@ -153,14 +182,27 @@
boolean isAbsouteUrl = false;
boolean needToResolve = false;
- if(urlString.startsWith("file:") && urlString.charAt(5) != '/')
+ // Bugzilla#5701: the below if is incorrect, if you read
+ // section 5.2 of RFC 2396. If the url did start with file:,
+ // it implies we should assume it's absolute and be done
+ // with resolving. Note that I'm not even sure why we put
+ // in the second check for '/' anyways -sc
+ //if(urlString.startsWith("file:") && urlString.charAt(5) != '/')
+ //{
+ // needToResolve = true;
+ //}
+ //else if (urlString.indexOf(':') > 0)
+ // Bugzilla#5701 comment out code end
+ if (urlString.indexOf(':') > 0)
{
- needToResolve = true;
- }
- else if (urlString.indexOf(':') > 0)
+ // If there is a colon to separate the scheme from the rest,
+ // it should be an absolute URL
isAbsouteUrl = true;
+ }
else if (urlString.startsWith(File.separator))
{
+ // If the url starts with a path separator, we assume it's
+ // a reference to a file: scheme (why do we do this? -sc)
urlString = "file://" + urlString;
isAbsouteUrl = true;
}
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-cvs-help@xml.apache.org