| | | | |
Install a c++ compiler and the c++ library (g++, libstdc++, libstdc++-dev). This is due to
the ``configure'' script being created with libtool <= 1.5.x, which tests for the
availability of a c++ compiler. This is a known libtool problem, and future versions of modxslt
configure scripts will be created using libtool >= 1.6. Either install a c++ compiler or
recreate the ``configure'' script by yourself (using autoconf).
| |
|
| |
You are probably using an older version of libmodxslt0,
or two or more versions of libmodxslt0 are available
on your system and apache is using the older one.
To solve the problem, make sure to run ``make install''
and to specify the correct --with-prefix to the
configure script (usually, --with-prefix=/usr),
and to remove any older libmodxslt0.
| |
|
| |
Upgrade the libpcre installed on your system at least to version
4.5.
| |
|
| |
mod-xslt uses some ISO C99 constructs. Is the error because of C99?
If yes, you should really update your compiler. It has been 14 years since the standard was approved,
and most version of gcc since 2004 have supported enough of it to compile modxslt.
If no, maybe you are missing some dependencies? Check out the wiki or the mailing list,
or file a bug. Visit www.modxslt.org for more details.
| |
|
| |
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.
| |
|
| |
You should also specify ``--with-apxs=...'' to force configure to use the right apxs.
Without this parameter, configure will use the first apxs detected on your system,
even if it is of the wrong apache version.
| |
|
| |
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. | |
|
| |
Latest version of mod-xslt don't add any comment at the end of your
page. Just upgrade :). If you still see comments, they must be added
by something else.
| |
|
|
|
| | | | |
Try to update your libxslt. Version up to 1.1.11
have a problem in handling doctype-public and doctype-system
attributes in the <xsl:output element. If you can't install/don't
have any newer version, you can either:
- remove any of doctype-public or doctype-system attributes
- change the xsl:output method to html, instead of xml
| |
|
| |
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 at
all (when no output could be generated). You get as much of the output as possible
when there is an error in your XPath expressions
or a non fatal error in your templates. Take a look to your web server logs to
know what exactly is going on.
| |
|
| |
mod-xslt does not check for document validitity (it doesn't care
about it). However, it does load external DTDs when ``<xml version... standalone="no"''.
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:
mod_xslt: http://127.0.0.1/yaslt/fuffa/dtd/faq.dtd:1:
mod_xslt: Content error in the external subset
mod_xslt: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
mod_xslt: ^
mod_xslt: http://127.0.0.1/yaslt/fuffa/dtd/faq.dtd:1:
mod_xslt: Extra content at the end of the document
mod_xslt: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
mod_xslt: ^
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 of the document the stylesheet
is to be applied to.
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. | |
|
| |
The ``&'' character has a special meaning in XML. Since it is used
inside the attribute of a tag, it is interpreted by the xml parsing library
as a special character. If you want to use ``&'' as a separator, you
need to use a regular expression like ``&[a-z]+[0-9]{2}&i''
which is exactly equivalent to ``/[a-z]+[0-9]{2}/i''.
| |
|
| |
You must use the attribute ``media-type'' of the ``<xsl:output...''
tag, much like in the example below:
<xsl:output method="html" media-type="text/fuffa"
indent="no" encoding="UTF8">
where the output mime-type is set to ``text/fuffa''.
| |
|
| | - file:// - asks for a stylesheet or for an entity to be
loaded directly by mod-xslt by reading the local file system.
Path will be calculated
starting from the root of the file system if a third ``/'' is
specified, otherwise it will be taken as a relative path from
the current directory (the real directory of the xml file being parsed).
By default, if no scheme is specified, the path is
assumed to be relative to the file system.
- http://localhost/ - asks for a stylesheet or for an entity
to be taken from the specifyed host (in this case localhost) using
the http protocol.
- local:// - is similar to both ``http://'' and ``file://'',
in the sense that the specified file will be accessed by using
the http protocol, but... the name of the server will be that of the
virtual host that received the request, and if the path doesn't
start with a ``/'' (leading to something like local:///file.html),
the url will be considered as relative to the current page.
This is useful when you have, for example, php scripts generating .xsl
files or .DTD.
Reading the README for more details is strongly encouraged. As an
example, imagine a browser requesting ``www.site.com/your/path/to/file.xml''.
If, in file.xml, you have ``local://file.xsl'', file.xsl will be accessed
using http as if it was ``http://www.site.com/your/path/to/file.xsl''.
If instead we had ``local:///file.xsl'', the address would be:
``http://www.site.com/file.xsl''. Note that, for various concerns, the
name of the virtual host (www.site.com) is taken from the ServerName
parameter in apache.
| |
|
| |
There's only one known condition in which case mod-xslt will crash
with segmentation fault, and it's not mod-xslt fault.
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 most of
the times.
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:
- specify something like --prefix=/usr --exec-prefix=/usr, to
get the libraries installed in /usr/lib, one of the directories
most system look into to search for libraries (thanks to
Boyan Dzambazov).
- specify something like --libdir=/usr/lib, to manually force
the place where you want mod-xslt libraries to be installed.
- on linux, add the line ``/usr/local/lib'' into the configuration
file /etc/ld.so.conf and run the command ``ldconfig'',
to tell your linux system to also look in /usr/local/lib.
| |
|
| |
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).
| |
|
|
|
| | | | |
Verify the correctness of your LoadModule directive
for mod-xslt in your apache 2.x configuration file. Probably, you
specified the wrong path: try to run something like ``apxs -q LIBEXECDIR''
or ``apxs2 -q LIBEXECDIR'' to know the correct one to use on your
system.
| |
|
| | 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 one of those instructions, otherwise
your xml files will be parsed by mod-xslt multiple times, one for each
of the directives you used. And while at the first pass the html will
be generated, during the second pass it would try to transform the html
into something else, leading to the errors you are seeing.
| |
|
|
|
|
|
| | | | |
In the log, you'll probably see something like:
fatal - couldn't load stylesheet for: file.xsl
http://127.0.0.1/yaslt/xslt/file.xsl:1:
Space required after the Public Identifier
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
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
| |
|
| |
For apache, local:// gets replaced with the name of the server the request
came from. Under certain circumstances, the server name used is the one
specified by the ServerName parameter in httpd.conf file. If that parameter
is wrongly configured, than the local:// request might fail. The error
you see in the log will be the one corresponding to the http error encountered
(most likely, "No such file or directory", meaning that the file is not there).
| |
|
| |
Take the number and run the command (from your console) ``modxslt-perror x''. It will tell
you what the problem is. I couldn't use ``strerror'', since this function is not
thread safe on many systems.
| |
|
| |
In your stylesheet, add the following xsl instruction:
<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.
| |
|
| |
For security reasons mod-xslt won't disclose any information about the errors
in your xml pages, and will return a 500 error page when:
- the file being parsed by mod-xslt is not a valid XML file
- a valid XSLT cannot be found
- the XSLT is having troubles translating the given XML file
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,
using
- in apache 1.3.x: the apache <file> directive or set the mime
type to text/plain.
You can also use the <modxslt-stylesheet pi without any href to tell mod-xslt
you don't want any xslt to be used.
| |
|
| |
I 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:
failed to load external entity "name.xsl"
fatal - couldn't apply stylesheet to: /tmp/name.tmp (file.xml)
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!). | |
|
|
|
| | | | |
Did you call mxslt_xml_preinit? Did you call it before
your application started to spawn threads? Well, make
sure you did...
| |
|
| |
Take care of writing the call to mxslt_error on one, single
line. If the line is too long, just live with it. The c99-strip
script cannot handle function calls that eat up multiple lines.
| |
|
|
|
|