#44269 [Bgs]: Inconsistent parameter validation

ID: 44269 User updated by: boen dot robot at gmail dot com Reported By: boen dot robot at gmail dot com Status: Bogus Bug Type: XSLT related Operating System: Windows XP SP2 PHP Version: 5.2.5 Assigned To: rrichards New Comment: I think you're misunderstanding where the issue is here. It's not that the errors are not part of LibXML's buffer... ok, so I thought they should be, I was wrong. Sorry about that. The real issue is that those errors don't always appear, and have different impacts depending on how you set the parameters. When using an array of name=>value pairs, the results should be the same as if you used a set of setParameter() calls with a single name/value pair each. In particular, parameters with invalid names and/or values should not be passed along and a warning should appear (or a catchable fatal error, or an exception...). All valid name/value pairs (whether in an array or not) should get passed to libxslt where the parameter may be ignored if it doesn't exist. What instead happens is that if a valid parameter is part of an array where a previous parameter is invalid, that parameter doesn't get passed. In addition, specifying this invalid parameter without an array (but in a stand alone setParameter() call) doesn't create the warning. In addition, specifying an invalid stand alone value shows a warning about wrong parameter count which is completely unrelated. Not to mention that the fallbacks of invalid values are different depending on whether the invalid value is in an array or not. Please review the initial examples again and tell me if this inconsistent behaviour (hence the name) is really a corrent one. Previous Comments: ------------------------------------------------------------------------ [2008-10-20 13:07:08] rrichards@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php All of the encountered errors are PHP errors as nothing has even been passed to the libxslt layer, so libxml_errors are never populated. Objects need to be convertible to strings to be used as parameters. Not passing convertible data results in exactly what you have seen. ------------------------------------------------------------------------ [2008-02-27 17:23:11] boen dot robot at gmail dot com Description: ------------ XSLTProcessor::setParameter() seems to be validating if its arguments are valid in XSLT context, but not always. What I'm even more curious about is that these warnings never get into the LibXML's error buffer. That is, libxml_get_errors() returns an empty array when such warnings are to be displayed (regardless of the libxml_use_internal_errors() value). To make description of the bug simpler, I'm only altering the $params array in the sample code below (which I used to isolate the bug(s?)). Another (minor) part of this issue is that the namespace is never validated to be an URI (I can live without that one though), regardless of whether two or three arguments are used. Reproduce code: --------------- <?php ini_set('display_errors', 'On'); $params = array(); libxml_use_internal_errors(true); $proc = new XSLTProcessor; $proc->importStylesheet(@DOMDocument::loadXML('<?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:param name="test1" /> <xsl:param name="test2" /> <xsl:template match="/"> test1: <xsl:value-of select="$test1"/><br /> test2: <xsl:value-of select="$test2"/><br /> </xsl:template> </xsl:stylesheet>')); $proc->setParameter(null, $params); echo $proc->transformToXML(DOMDocument::loadXML('<a/>')); print_r(libxml_get_errors()); ?> Expected result: ---------------- $params = array( 'test1'=>'legal value', '1'=>'invalid parameter name, but a legal value', 'test2'=>'another legal value'); Should create a warning for $params being an invalid parameter array, ideally pointing explicitly to the "1" parameter, and still apply "test2", since it's a valid parameter. The warning should be part of the LibXML error buffer. $params = array( 'test1'=> new XSLTProcessor, 'test2'=>'legal value'); Should generate a warning in LibXML's error buffer because of the XSLTProcessor object. This error belongs there, as "normal" arrays can have objects as their values. The same is applicable for any other object, though I'm not sure if __toString() has any influence on the outcome with setParameter(). I believe it should be tried before a warning is reported, and if it's not available, "test1" should not be populated at all (or should I say its last successfully applied value should be used during the transformation). The same should apply if setParameter() was used with three arguments instead of two, like $proc->setParameter(null, 'test1', 'legal value'); $proc->setParameter(null, '1', 'invalid parameter name, but a legal value'); $proc->setParameter(null, 'test2', 'another legal value'); and $proc->setParameter(null, 'test1', new XSLTProcessor); $proc->setParameter(null, 'test2', 'legal value'); respectively. Actual result: -------------- $params = array( 'test1'=>'legal value', '1'=>'invalid parameter name, but a legal value', 'test2'=>'another legal value'); Shows a warning about $params not being a valid parameter array and doesn't apply any parameter in the array appearing after the first invalid parameter (in the case above: "test2"). No entry in LibXML's error buffer is generated. $params = array( 'test1'=> new XSLTProcessor, 'test2'=>'legal value'); Throws a catchable fatal error appearing on screen, and executes the transformation, giving "test1" a value of the string "Object", and giving "test2" its expected "legal value". When using three arguments instead of two, no warnings ever occur anywhere for the first case, and $proc->setParameter(null, 'test1', new XSLTProcessor); shows "Wrong parameter count" warning, instead of trying to turn the object into string, and using $proc->setParameter(null, 'test1',(string) new XSLTProcessor); shows the same error as when using an array, only it doesn't populate "test1" with the value "Object". (I haven't tried it, but I'm guessing resources may have similar issues) ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=44269&edit=1