DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5701>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5701 Bad URI absolutizing Summary: Bad URI absolutizing Product: XalanJ2 Version: 2.2.x Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: org.apache.xml.utils AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The methods getAbsoluteURI(String) and getAbsoluteURI(String, String) are resolving relative URIs in a way which is not conforming with section 5.2 of RFC 2396. Below are the interesting snippets of the code: 133: else if (url.startsWith("file:") && url.charAt(5) != '/') 134: { 135: url = getAbsoluteURIFromRelative(url.substring(5)); 136: } 156: if(urlString.startsWith("file:") && urlString.charAt(5) != '/') 157: { 158: needToResolve = true; 159: } Section 5.2, bullet 3) of RFC2396 states: "3) If the scheme component is defined, indicating that the reference starts with a scheme name, then the reference is interpreted as an absolute URI and we are done. [...]" So, if the candidate URI starts with "file:" it must be considered absolute, and there is no need to check whether the path component starts with "/" or not. The problem with the current code is that a Windows file URI like file:c:/temp/foo.txt is absolutized, although it is already an absolute URI with an opaque path component. With a base URI of e. g. file:c:/base/bar.txt this results in file:c:/base/c:/temp/foo.txt /Gregor
