-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem parsing relative URLs #527
Comments
Hi @mebibou. Sorry for looking only now into this old issue… If you still face the issue, could you possibly send a sample? |
sorry not on this project anymore |
ok, thanks for answering! I'll close as |
I'm finding the base tag really messes up epubcheck. If I add in If I do a little more silliness and go up and down a level - |
Oh. I tried harder and was able to reproduce. I'm wondering what the heck I missed earlier. 🤔 Thanks @mattgarrish for double-checking! I'll dig deeper now… |
- re-implement the `PathUtil` class to fix various URI resolution issues - remove the 3-arg `resolveRelativeReference` method - systematically resolve URI references in Content Documents against the base URI - the base URI is initially set to the document path, and overriden with `xml:base` attributes or HTML’s `base` element - add more exhaustive tests for URI normalization/resolution logic What this PR doesn’t do: - cleanup the many uses of paths strings, where we should really use URIs. The `PathUtil` code is mostly a hack, when we should rely on more robust URI normalization/resolution logic from URIs. - implement proper base resolution logic (`xml:base` should be deprecated, and only the first `base` element should be taken into account). See also w3c/epub-specs#1217. Fixes #527
- re-implement the `PathUtil` class to fix various URI resolution issues - remove the 3-arg `resolveRelativeReference` method - systematically resolve URI references in Content Documents against the base URI - the base URI is initially set to the document path, and overriden with `xml:base` attributes or HTML’s `base` element - add more exhaustive tests for URI normalization/resolution logic What this PR doesn’t do: - cleanup the many uses of paths strings, where we should really use URIs. The `PathUtil` code is mostly a hack, when we should rely on more robust URI normalization/resolution logic from URIs. - implement proper base resolution logic (`xml:base` should be deprecated, and only the first `base` element should be taken into account). See also w3c/epub-specs#1217. Fixes #527
- re-implement the `PathUtil` class to fix various URI resolution issues - remove the 3-arg `resolveRelativeReference` method - systematically resolve URI references in Content Documents against the base URI - the base URI is initially set to the document path, and overriden with `xml:base` attributes or HTML’s `base` element - add more exhaustive tests for URI normalization/resolution logic What this PR doesn’t do: - cleanup the many uses of paths strings, where we should really use URIs. The `PathUtil` code is mostly a hack, when we should rely on more robust URI normalization/resolution logic from URIs. - implement proper base resolution logic (`xml:base` should be deprecated, and only the first `base` element should be taken into account). See also w3c/epub-specs#1217. Fixes #527
When using relative URLs for resources in html files, epubcheck complains about Invalid path. Example:
OEBPS/test/index.html
OEBPS/css/test.css
When epubcheck parses the file
OEBPS/test/index.html
, the following error will show up:ERROR: test.epub: could not parse OEBPS/test/index.html: Invalid path: ./../css/test.css
.If I change the
base
to:<base href="./test/">
then there is no error but when loading the epub in a reader it cannot find thetest.css
fileThe text was updated successfully, but these errors were encountered: