Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46990
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 207.58.142.213 as permitted sender)
Message-ID: <4B792DF5.3020203@php.net>
Date: Mon, 15 Feb 2010 06:20:21 -0500
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Sokolov Evgeniy <ewgraf@gmail.com>
CC: internals@lists.php.net
References: <d0c581731002130029x1258a8b3n4ac1d9c4e52b4b23@mail.gmail.com>	 <4B77F81C.5080609@php.net> <d0c581731002140843g2fdfa026o7d8cb7166ddc3cf9@mail.gmail.com>
In-Reply-To: <d0c581731002140843g2fdfa026o7d8cb7166ddc3cf9@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: help with php bug #47532
From: rrichards@php.net (Rob Richards)

Sokolov Evgeniy wrote:
> If you are very busy, you can answer "yes, yes, no" :)
>
> 1.
>   
>> Setting the value using the value property should behave like setting the value via
>> the DOMAttr constructor - input should be treated as literal text
>>     
> But in this case value does not be treated:
> $attr = new DOMAttr('test', 'foo&amp;bar');
> var_dump($attr->value);
> string(11) "foo&amp;bar"
>
> So, this is bug?
> May be I misunderstood something?
>   


The above output is correct. Values of a DOMAttr deal strictly with text 
literals. The only time escaping should be performed is when the 
attribute value is being serialized in a document context - i.e. 
DOMDocument::saveXML(DOMAttr) - which would end up outputting the value 
foo&amp;amp;bar

> 2. I saw you comment in the bug page.
> May I write test for this cases and in this testcase show how avoid this "bug"?
>   

Test cases are more than welcome.
> 3. May be add $DOMAttr->getEntitiesValue() method? Because I think
> htmlspecialchars_decode function are not equal libxml function
> xmlEncodeEntitiesReentrant (this function use entity table). Is this
> function used as analog for htmlspecialchars_decode in libxml?
> Unfortunatelly, I can't find libxml analog function for
> htmlspecialchars php function :(
>   

htmlspecialchars would work fine to at least allow the assignment in all 
cases as the issue really only revolves around the use of & and <. Due 
to the nature of the issue I am thinking about the possibility of a 
rawValue property on DOMAttr which would conform to the correct setter 
behavior.
>
> Thank you.
>
> 2010/2/14 Rob Richards <rrichards@php.net>:
>   
>> Sokolov Evgeniy wrote:
>>     
>>> Hi, I wont fix this bug: http://bugs.php.net/bug.php?id=47532, but
>>> have some questions. Can you help me?
>>>
>>> There is the test case: http://pastebin.org/91030
>>>
>>> First, I careful that when we fix this bug, we have broken BC, because
>>> now when we write $attr->value = "foo&amp;bar"; - value has been
>>> escaped and in var_dump($attr->value) we got "foo&bar". For fix this
>>> bug we must remove escaping. This is right?
>>>
>>>
>>> Second, for remove escaping I think we need use this patch:
>>>
>>> Index: attr.c
>>> ===================================================================
>>> --- attr.c      (revision 294790)
>>> +++ attr.c      (working copy)
>>> @@ -193,7 +193,7 @@
>>>                convert_to_string(newval);
>>>        }
>>>
>>> -       xmlNodeSetContentLen((xmlNodePtr) attrp, Z_STRVAL_P(newval),
>>> Z_STRLEN_P(newval) + 1);
>>> +       xmlNodeAddContentLen((xmlNodePtr) attrp, Z_STRVAL_P(newval),
>>> Z_STRVAL_P(newval) + 1);
>>>
>>>        if (newval == &value_copy) {
>>>                zval_dtor(newval);
>>>
>>>
>>> This patch fix this cases:
>>> $attr = new DOMAttr('test', 'foo&amp;bar');
>>> var_dump($attr->value);
>>> $attr->value = "foo&amp;bar";
>>> var_dump($attr->value);
>>>
>>> but in this case we got empty value:
>>> $doc = new DOMDocument;
>>> $attr = $doc->createAttribute("foo");
>>> $attr->value = "foo&amp;bar";
>>> var_dump($attr->value);
>>>
>>> Can you explain why?
>>> in first two cases wiil be call xmlNewProp libxml2 function, in last
>>> case - xmlNewDocProp. Both this functions return same variable type.
>>>
>>>
>>>       
>> The patch is incorrect as its changing the wrong thing. The retrieval of the
>> value is correct, it's the setting which has an issue. Setting the value
>> using the value property should behave like setting the value via the
>> DOMAttr constructor - input should be treated as literal text. Wont be
>> changing the behavior of the value property due to BC.
>>
>> Rob
>>
>>
>>     
>
> --
> Evgeniy
>
>   

Rob