This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7231 - External DTDs may still be resolved
Summary: External DTDs may still be resolved
Status: RESOLVED FIXED
Alias: None
Product: mobileOK Basic checker
Classification: Unclassified
Component: Java Library (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: fd
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-06 09:58 UTC by fd
Modified: 2009-08-06 10:31 UTC (History)
0 users

See Also:

Attachments

Description fd 2009-08-06 09:58:08 UTC 
As detailed in the CatalogResolver javadoc, the XML parser may still attempt to resolve external DTDs using the system ID of the DTD if our entity resolver cannot map it to a local DTD file:
[[
If no mapping is found (or an error occurs attempting to open the mapped value as an input source), null is returned and the system will use the specified system identifier as if no entityResolver was specified.
]]
http://xml.apache.org/commons/components/apidocs/resolver/org/apache/xml/resolver/tools/CatalogResolver.html#resolveEntity(java.lang.String,%20java.lang.String)

This means that CommonCatalogResolver cannot guarantee that unknown DTDs won't be resolved.

Two solutions:
1. detect the DTD before starting the validation and skip it whenever the DTD is not one of the well-known DTDs of the mobileOK Checker.
2. make sure that an exception is thrown whenever a DTD cannot be resolved locally.
Comment 1 fd 2009-08-06 10:31:46 UTC 
Changed CommonCatalogResolver to return an invalid "%" URI that triggers a MalformedURLException in validateMarkup whenever the system ID cannot be found in the local catalog.