Req #53950 [Com]: Add a way to configure where libxml searches for Catalog Files

Edit report at https://bugs.php.net/bug.php?id=53950&edit=1 ID: 53950 Comment by: Marko dot Voss at fiz-Karlsruhe dot de Reported by: gordon at onlinehome dot de Summary: Add a way to configure where libxml searches for Catalog Files Status: Assigned Type: Feature/Change Request Package: *XML functions Operating System: any PHP Version: Irrelevant Assigned To: rrichards Block user comment: N Private report: N New Comment: > The user can change the default catalog behaviour by redirecting queries to its own set of > catalogs. This can be done by setting the XML_CATALOG_FILES environment variable to a list of > catalogs, an empty one should deactivate loading the default /etc/xml/catalog default catalog. If I understand this right, you can use this code to set your own catalog: setenv("XML_CATALOG_FILES=/path/to/catalog.xml"); I tried that, because I have to use xml catalog somehow, without overwriting the http stream wrapper, which is a non-threadsafe way to do this. However, the catalog.xml I specified using setenv seems not to be used by libxml2. Previous Comments: ------------------------------------------------------------------------ [2011-02-08 19:27:00] rrichards@php.net Assign to self as I asked him to open this ------------------------------------------------------------------------ [2011-02-08 19:18:43] cataphract@php.net > This, by itself, makes it inviable to write a PHP function that allows > replacing the default catalog unless some (probably expensive, since a > catalog file must be read) on request startup/shutdown is used. The unless part doesn't actually make sense in the multi-threading versions of PHP. ------------------------------------------------------------------------ [2011-02-08 19:14:49] cataphract@php.net I know very little of libxml2, but as far as I infer from http://xmlsoft.org/catalog.html and from the code in catalog.c, there is no way to specify a global catalog in a thread-local manner. This, by itself, makes it inviable to write a PHP function that allows replacing the default catalog unless some (probably expensive, since a catalog file must be read) on request startup/shutdown is used. libxml2 supports per-document catalogs, but from what I see, your document must contain an oasis-xml-catalog processing instruction, like this: <?xml version="1.0"?> <?oasis-xml-catalog catalog="http://example.com/catalog.xml"?> <!DOCTYPE doc PUBLIC "-//Example//DTD Document V1.0//EN" "http://www.example.com/schema/doc.dtd"> There is another alternative, which is using an external entity loader (see http://xmlsoft.org/html/libxml-parser.html#xmlSetExternalEntityLoader ), but this is less convenient, though probably we could also expose some functions to deal with catalogs for use in the user-supplied callback. I could implement this, but I'm hopping someone else with more libxml2 knowledge could tell if my analysis is correct. ------------------------------------------------------------------------ [2011-02-07 17:16:37] gordon at onlinehome dot de Description: ------------ Libxml can use catalog files to provide a local cache mechanism allowing to load the entities associated to public identifiers or remote resources. There is currently no way to configure the catalog file path from PHP. Configuring the path in libxml itself seems possible: > The user can change the default catalog behaviour by redirecting queries to its own set of > catalogs. This can be done by setting the XML_CATALOG_FILES environment variable to a list of > catalogs, an empty one should deactivate loading the default /etc/xml/catalog default catalog. It would be nice if PHP's libxml extension would provide a way to set the path somehow. This could be helpful when validating documents with remote System Identifiers, like any HTML DTD. Or simply to bundle files with an application. Related Resources: - http://xmlsoft.org/catalog.html - http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic - http://bugs.php.net/48080 - http://bugs.php.net/32426 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=53950&edit=1