mod-xslt uses some ISO C99 constructs that are supported by very few compilers. You
should:
Althought libxml2 is thread safe and libxslt is not very thread sensitive, they both suffer some problems if used ``from modules'' by web servers like apache or apache2 (take a look to the thread on the libxml and libxslt mailing lists).
mod-xslt tries to lessen the impact of libxml/libxslt lack of support for modularized environments by trying to use some libxml2 internal functions.
The message just warns you that some compatibility layers have been enabled since some of the needed functions were missing. If you want to get rid of the warning, please patch the library (read README-Patches.sgml). Most of the times, you can just ignore this message since the ``compatibility layer'' will take care of everything.
By default, mod-xslt will try to fetch any external entity using directly the file system (which is kind of faster). However, if the file system is used, php, perl, ssi, are not parsed and the document is used raw as it is.
If you want to use dynamically generated stylesheets, use a http:// or local:// url, so mod-xslt will load the document by asking the web server for it.
If you want to use dynamically generated xml files, tell mod-xslt about that. To know how, take a deeper look to the manual. It seems like you need it.
At time of writing, to disable the ``signature'' at the end of the page, you must compile mod-xslt with the MXSLT_DISABLE_SIGNATURE macro defined.
In order to do so, you should run: ./configure CFLAGS="-DMXSLT_DISABLE_SIGNATURE" ..., or, CFLAGS="-DMXSLT_DISABLE_SIGNATURE" make or make CFLAGS="-DMXSLT_DISABLE_SIGNATURE", depending on your shell or your own taste...
mod-xslt doesn't care about the validity of documents. It just check for them to be ``well-formed''. However, DTDs may specify default values for some attributes or external entities, so they need to be loaded. However, loading one more additional file may slow things down, especially if DTDs are stored remotely. mod-xslt will thus try to load DTDs only if you specify the ``standalone="no"'' attribute in the xml declaration of your document.
Just set ``standalone'' to ``yes'' if you don't want mod-xslt to even try to load the DTD.
There's currently a bug being investigated either in libxslt or mod-xslt2, such as xsl:output elements in imported documents are ignored...
A workaround is just to put xsl:output in the main .xsl stylesheet, instead of putting it in imported documents...
No, it is not. You get a 500 error page when the xslt is not valid xml (it is not
well-formed), contains invalid xsl instructions or when it cannot get parsed
mod-xslt
When a locally stored DTD (== on a locally mounted disk) cannot be read for some reason an error is printed in the logs but parsing goes on. When the DTD is fetched from a remote URL, the error is fatal and parsing is stopped with a 500 error status.
If this is the case, you'll see in your logs something like: Does this look familiar to you? This is not my fault. libxml2 http client does not check for the status of remote servers, and tries to parse any returned document, even when the returned document is an error page (like those returned by a 400 or 500 status).
However, when a DTD is not available nothing bad happens, while if it is available but it is not a valid DTD (contains junk, trash, fuffa, html or something that does not make it a valid DTD), a fatal error arise.
At time of writing, and according to the libxml (2.5.9) mailing list, the lack of check of the status of remote servers and the lack of an API to allow users to decide how to handle error pages is a ``feature''.
Furthermore, I couldn't find any good way to disable this feature, that didn't involve patching the library or rewriting the whole http client (which is something I'm not going to do).
If this problem really annoies you, patch your library and let your voice be heard by the upstream team.
The most common source of errors is the MimeType specified with
XSLTSetStylesheet or XSLTDefaultStylesheet. Infact, both parameters
must be followed by the mime type
Additionally, mime types are configurable for most web
servers, so it is quite easy to specify the wrong mime type
for the given document. As an example, if we want to apply
stylesheet.xsl to all .xml documents, we need to use something
like:
[...]
XSLTSetStylesheet application/xml stylesheet.xsl
[...]
or
XSLTSetStylesheet text/xml stylesheet.xsl
to tell your web server you want all documents of type
text/xml and application/xml to be transformed by applying
stylesheet.xsl...
Web servers like apache use parameters like AddType to decide which mime type to use for every document, or files like /etc/mime.types.
Remember: XSLTSetStylesheet forces the usage of a given stylesheet for a given kind of documents, where the document kind is indicated thanks to its mime type. XSLTDefaultStylesheet provides a stylesheet to be used in case there is no XSLTSetStylesheet and no stylesheet is specified in the document itself.
Remember: XSLTSetStylesheet forces the usage of a given stylesheet for a given kind of documents, where the document kind is indicated thanks to its mime type. XSLTDefaultStylesheet provides a stylesheet to be used in case there is no XSLTSetStylesheet and no stylesheet is specified in the document.
It just means you're using a <xsl:fallback... tag under a <mod-xslt:header tag, or in a ``strange'' place (like as a top element).
I believe it to be a libxml2 bug, which I already took care of reporting.
However, at time of writing it has not been corrected (libxml 2.5.9).
To avoid the problem, that under some conditions may cause a Segmentation Fault, you can rely on some dirty hacks provided by mod-xslt.
The Segmentation Fault is caused by yet another bug that sometimes combines badly with this bug: the ``xsltApplyOneTemplate: fallback ...'' error message is printed by libxml by calling the application error handler by using the arguments of the debug handler.
This latest problem is detected by mod-xslt code most of the times. However, to get rid of both problems forever, you should 1 - patch the library to avoid error messages to be printed when the fallback tag is correctly used 2 - patch the library to avoid the error handler to be called with the debug arguments.
If you don't want to patch the library, you can enable two dirty hacks in mod-xslt: the first one will try to remove the fallback nodes where libxml would illegally comply, while the second one will enable the debug handler with the same arguments as the error handler, in order to always avoid the SEGFAULT.
Read README-Patches.sgml for more details.
<xsl:output method="html" media-type="text/fuffa"
indent="no" encoding="UTF8">
where the output mime-type is set to ``text/fuffa''.
There's
The problem is caused by libxslt calling the ``error'' handler with the
arguments of the ``debug'' handler under certain conditions.
mod-xslt cannot really detect when this error verifies, but some ``parachutes''
have been written to avoid this problem
To get rid of the problem, you should patch libxslt.
However, keep in mind that the highlited segfault will always be triggered by an error in your xslt file, error that is ``printed uncorrectly'' by the libxslt library.
If you don't want to patch libxslt, you can compile mod-xslt with ``--enable-libxslt-hack''. By enabling this option, mod-xslt will enable libxslt debugging by specifying an handler which accepts the same arguments as the error one.
However, with debugging enabled, the debug function will always be called (even if the output is discarded), and may possibly slow things down.
If this error really bothers you, you'd be better patch the library.
For more details, please read ``README-Patches''.
XSLTAddFilter tells mod-xslt to watch a given mime type to see if, after being executed by apache, it outputs xml code to be parsed.
XSLTAddForce tells mod-xslt to parse anything sent as output by apache while parsing the given mime type.
The only difference between the two is that the first one looks at the output mime type, and ignores the document if it is not text/xml, while the second one parses anything the script may send.
When you configured and installed mod-xslt, you didn't specify the correct ``--prefix'' or ``--libdir''. This means that everything got compiled and installed correctly, but that your system is not able to find the installed libraries since they have not been placed in the directories it is looking into.
In order to solve the problem, either:
If you are not using any apache module that links to libxml2 (you can check by using ``ldd'' on each apache module you are using) beshide mod-xslt itself, you should ignore this warning.
In any other case, mod-xslt will try to lessen the impact of libxml2 lack of support for modularized applications by using some libxml2 internal functions available only when libxml2 is compiled with threading support.
If you want to use other apache modules that are linked to libxml2, you should really make sure your libxml2 has been compiled with threading support.
Even with threading support, however, some problems may arise, depending on how the other modules make use of libxml or libxslt.
Use ``configure --with-sapi='apache1' --with-apxs='/path/to/apxs'''. You can find where ``apxs'' is installed on your system by running something like ``whereis apxs'', ``which apxs'', ``locate apxs'' or ``find / -name apxs -perm +0100''.
Without the ``--with-apxs'' parameter, configure will try to use the first apxs found in some common places.
Great care has been taken to allow mod-xslt to run even when some other apache 1.3 module is linked with mod-xslt. Unluckily, libxml and libxslt were not made with modularized softwares in mind and keep some variables shared and ``secret'', so I can't do much about them.
However, if you enable threading support in libxml2, mod-xslt will be able to ``copy'' and ``restore'' most of the important variables and to work with ``most'' of other apache modules making use of libxml (as long as they don't change libxml memory handlers).
libxslt condition is worse: althought it uses much fewer global variables, it doesn't have any additional support for multithreading. However, the lower number of global variables should make it usable in most condition, even if errors won't be handled correctly (will probably go to the wrong place).
Use ``configure --with-sapi='apache2' --with-apxs='/path/to/apxs2'''. You can find where ``apxs2'' is installed on your system by running something like ``whereis apxs'', ``which apxs'', ``locate apxs'' or ``find / -name apxs -perm +0100''.
Without the ``--with-apxs'' parameter, configure will try to use the first apxs found in some standard places.
Note that depending on how apache2 was compiled on your system, ``apxs'' may as well be named ``apxs2''.
Great care has been taken to keep mod-xslt thread safe, althrought some of the libraries it uses are not. Most of the problems were due to libxslt not supporting multithreaded applications (at time of writing - since mod-xslt needs to change the error context handler for every apache request and requests are processed paralleley by multiple threads).
The problem has been worked around by using some tsd variables, and you should not have any problem. However, you may see your error messages going to the wrong place if you ever decide to use mod-xslt with any other apache module linked with libxslt.
Great care has been taken to allow mod-xslt to run even when some other apache 2.x module is linked with mod-xslt. Unluckily, libxml and libxslt were not made with modularized softwares in mind and keep some variables shared (among modules) and ``secret'', so I can't do much about that.
However, if you enable support for threading in libxml2, mod-xslt will be able to ``copy'' and ``restore'' most of the important variables and to work with ``most'' of other apache modules making use of libxml (as long as they don't change libxml memory handler).
libxslt condition is worse: althought it uses much fewer global variables, it doesn't have any additional support for multithreading. However, the lower number of global variables should make it usable in most condition, even if errors won't be handled correctly (will probably go to the wrong place or cause a segfault, let me know if it happens).
Take a look to your apache.conf or httpd.conf, whatever it is called on your system. You probably specified more than one ``AddOutputFilter'', ``SetOutputFilter'' or ``AddOutputFilterByType''.
You need to specify only
In the log, you'll probably see something like:
And, if you look carefully to the url of your stylesheet, you'll see that it is loaded from a ``http://'' or ``local://'' url.
This error usually shows up when the xsl file is stored in a mod-xslt handled directory, and is due to apache (correctly) believing that both .xml and .xsl files are of type ``text/xml''.
When the xml file is parsed, the xsl file is fetched, but, as being fetched using a remote url, it is parsed again by apache. apache verifyes the file is of type ``text/xml'', and calls mod-xslt again to parse the stylesheet. However, the stylesheet cannot be parsed since it does not contain xml-stylesheet or modxslt-stylesheet directive, causing the sub-request to fail and mod-xslt to return a 500 error page, which, in turn, cannot be used by mod-xslt as a .xslt stylesheet (as not being even a valid .xml page).
To solve the problem, either disable mod-xslt in the directories where
you store .xsl files or tell apache ``.xsl'' files are of type
``text/xsl'', using something like:
AddType text/xsl .xsl
<xsl:output
method="html"
omit-xml-declaration="yes"
encoding="UTF-8"
indent="no"
doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" />
Unless you use the above xsl instructions, the xsl processor assumes that
the output will still be valid xml, and prepends the correct xml headers.
The browser, when receiving the document, thinks that the document is still
.xml, and tries to parse it.
When you ask mod_xslt to parse a file, that file will either be parsed or an error given back to the user. mod-xslt won't give away the source of your xml files or any information about the errors they contain (unless you ask for it). If you want to know what caused mod-xslt to return the error, read the error.log of your server.
If you want to return the xml source, just disable mod-xslt for the given file, usingI got several questions like this, and most of the times they were related to the language parser generating errors in the ``html'' output. Consider php as an example: when an error verifies in your code, like a wrong mysql query or something similar, php inserts an error text in what it thinks to be an html document. However, the document is not html and the error text is not written using valid xml, causing mod-xslt to complain about the validity of the xml document.
However, the xml will be invalid only when your code encounters an error, leading to ``random'' errors from ``mod-xslt''. To trace the problem down, I suggest you take a good look to the error log and disable the unlinking of temporary files or enable the store of ``intermediate files'' (depends on the SAPI being used). In the temporary file, you will get the xml file generated by your script that mod-xslt had to parse.
This problem often shows up when the privileges of the web server do not allow it to access the xslt document or any external entity required by the xml document. In the error log, you should see something like: As shown in the messages above, libxslt is not able to open ``name.xsl''. In this case ``name.xsl'' either does not exist or cannot be opened by the web server for privilege problems (verify the .xsl file can be read by the web server!).