This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There seems to be a difference in behavior for the CatalogResolver class between The CommonCatalogResolver class in HTTPXHTMLResource makes sure that DTDs are fetched from the local catalog, and not retrieved over HTTP. There seems to be a but in some versions of CatalogResolver in Java 1.5 that makes it return something like: file://firstdir/[rest of the path to the dtd] instead of: file:///firstdir/[rest of the path to the dtd] That's a problem when a DTD that is not in the catalog but still matches prefixes defined in the catalog properties (e.g.: www.w3.org). In that case, the InputSource returned by resolveEntity contains no stream but sets the systemId to "file://[path to dtd]" (apart from the missing "/", this behavior is correct AFAICT). The SAXParser then tries to retrieve the file, and thinks "firstdir" is a hostname. It then raises an UnknownHostException, not caught in HTTPXHTMLResource (we only expect FileNotFoundException to be raised when the DTD can't be found in the catalog).
That seems to match a known old bug in Java: Bug 6326037 http://bugs.sun.com/view_bug.do?bug_id=6326037 ... fixed in Java 1.6 I added an additional check in resolveEntity to add the missing "/" when needed.