aboutsummaryrefslogtreecommitdiffstats
path: root/src
diff options
context:
space:
mode:
authorJeremias Maerki <jeremias@apache.org>2005-09-05 15:31:04 +0000
committerJeremias Maerki <jeremias@apache.org>2005-09-05 15:31:04 +0000
commit2b9729a5db839ce49bd9b8bd23ff344aa26a8ae7 (patch)
tree85b8f09146a281f5200fa04aa98b2aeb2357308b /src
parent77d7f2c24a27274e16907f41368b15a091807c38 (diff)
downloadxmlgraphics-fop-2b9729a5db839ce49bd9b8bd23ff344aa26a8ae7.tar.gz
xmlgraphics-fop-2b9729a5db839ce49bd9b8bd23ff344aa26a8ae7.zip
Not sure if it's the best solution but this changes the following:
- Enable plain filenames (without "file:" scheme) as URI. FOURIResolver tries to create a java.io.File to access the file. - If after removing the scheme from a file: URL the string still contains a ":" it is likely an absolute Windows path for which the user forgot to specify a leading "/", i.e.: file:C:/Temp/test.txt --> file:/C:/Temp/test.txt git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@278779 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'src')
-rw-r--r--src/java/org/apache/fop/apps/FOURIResolver.java86
1 files changed, 50 insertions, 36 deletions
diff --git a/src/java/org/apache/fop/apps/FOURIResolver.java b/src/java/org/apache/fop/apps/FOURIResolver.java
index ce311bce9..5b73a66fd 100644
--- a/src/java/org/apache/fop/apps/FOURIResolver.java
+++ b/src/java/org/apache/fop/apps/FOURIResolver.java
@@ -18,6 +18,7 @@
package org.apache.fop.apps;
+import java.io.File;
import java.net.MalformedURLException;
import java.net.URL;
import javax.xml.transform.Source;
@@ -62,52 +63,65 @@ public class FOURIResolver
throws javax.xml.transform.TransformerException {
URL absoluteURL = null;
- URL baseURL = toBaseURL(base);
- if (baseURL == null) {
- // We don't have a valid baseURL just use the URL as given
+ File f = new File(href);
+ if (f.exists()) {
try {
- absoluteURL = new URL(href);
- } catch (MalformedURLException mue) {
- try {
- // the above failed, we give it another go in case
- // the href contains only a path then file: is assumed
- absoluteURL = new URL("file:" + href);
- } catch (MalformedURLException mfue) {
- log.error("Error with URL '" + href + "': " + mue.getMessage(), mue);
- return null;
- }
+ absoluteURL = f.toURL();
+ } catch (MalformedURLException mfue) {
+ log.error("Could not convert filename to URL: " + mfue.getMessage(), mfue);
}
} else {
- try {
- /*
- This piece of code is based on the following statement in RFC2396 section 5.2:
+ URL baseURL = toBaseURL(base);
+ if (baseURL == null) {
+ // We don't have a valid baseURL just use the URL as given
+ try {
+ absoluteURL = new URL(href);
+ } catch (MalformedURLException mue) {
+ try {
+ // the above failed, we give it another go in case
+ // the href contains only a path then file: is assumed
+ absoluteURL = new URL("file:" + href);
+ } catch (MalformedURLException mfue) {
+ log.error("Error with URL '" + href + "': " + mue.getMessage(), mue);
+ return null;
+ }
+ }
+ } else {
+ try {
+ /*
+ This piece of code is based on the following statement in RFC2396 section 5.2:
- 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. Otherwise, the reference URI's
- scheme is inherited from the base URI's scheme component.
+ 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. Otherwise, the reference URI's
+ scheme is inherited from the base URI's scheme component.
- Due to a loophole in prior specifications [RFC1630], some parsers
- allow the scheme name to be present in a relative URI if it is the
- same as the base URI scheme. Unfortunately, this can conflict
- with the correct parsing of non-hierarchical URI. For backwards
- compatibility, an implementation may work around such references
- by removing the scheme if it matches that of the base URI and the
- scheme is known to always use the <hier_part> syntax.
+ Due to a loophole in prior specifications [RFC1630], some parsers
+ allow the scheme name to be present in a relative URI if it is the
+ same as the base URI scheme. Unfortunately, this can conflict
+ with the correct parsing of non-hierarchical URI. For backwards
+ compatibility, an implementation may work around such references
+ by removing the scheme if it matches that of the base URI and the
+ scheme is known to always use the <hier_part> syntax.
- The URL class does not implement this work around, so we do.
- */
+ The URL class does not implement this work around, so we do.
+ */
- String scheme = baseURL.getProtocol() + ":";
- if (href.startsWith(scheme)) {
- href = href.substring(scheme.length());
+ String scheme = baseURL.getProtocol() + ":";
+ if (href.startsWith(scheme)) {
+ href = href.substring(scheme.length());
+ }
+ if ("file:".equals(scheme) && href.indexOf(':') >= 0) {
+ href = "/" + href; //Absolute file URL doesn't have a leading slash
+ }
+ absoluteURL = new URL(baseURL, href);
+ } catch (MalformedURLException mfue) {
+ log.error("Error with URL '" + href + "': " + mfue.getMessage(), mfue);
+ return null;
}
- absoluteURL = new URL(baseURL, href);
- } catch (MalformedURLException mfue) {
- log.error("Error with URL '" + href + "': " + mfue.getMessage(), mfue);
- return null;
}
}
+
try {
return new StreamSource(absoluteURL.openStream(), absoluteURL.toExternalForm());
} catch (java.io.IOException ioe) {