[PHP-DEV] RE: [PHP-QA] PHP 4.0.5 Release Candidate testing
The nl2br() change shouldn't have a big effect as all browsers should be
able to understand br / , if it were br/ then most browsers would choke
on it (Except IE).
Karl Austin
KDA Web Services
-Original Message-
From: Alexander Feldman [mailto:[EMAIL PROTECTED]]
Sent: 02 April 2001 10:00
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [PHP-QA] PHP 4.0.5 Release Candidate testing
Hi,
These are the results and questions from some tests I run yesterday on the
last 4.0.5 release candidate. Note that all differences are from PHP
4.0.4pl1.
1. The function array_flip($array) puts one extra zero byte at the end of
each element in the return array thus making the result non binary safe.
2. The nl2br function was modified to produce the correct tag br /
instead the opening only one br. Wouldn't this affect somehow the
existing applications? The nl2br() function is widely used and all
modification to its output should be done *extremely* carefully.
3. The count_chars() function returns different result from the 4.0.4pl1
count_chars() function.
4. Where is the connection_timeout() function. Was it removed on purpose?
5. The following expression returns empty string:
get_cfg_var("error_reporting") (I think this may be my problem in the
testing).
Best regards:
--
Alexander Feldman
Zend Technologies Ltd.
phone: +972 3 6139665 ext. 113, fax: +972 3 6139671
http://www.zend.com/
--
PHP Quality Assurance Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
On Mon, 02 Apr 2001, Alexander Feldman wrote: Hi, These are the results and questions from some tests I run yesterday on the last 4.0.5 release candidate. Note that all differences are from PHP 4.0.4pl1. 1. The function array_flip($array) puts one extra zero byte at the end of each element in the return array thus making the result non binary safe. I've just fixed it in CVS. 3. The count_chars() function returns different result from the 4.0.4pl1 count_chars() function. Examples? -Andrei "The only true currency in this bankrupt world is what we share with each other when we're uncool." -- Lester Bangs, from the film 'Almost Famous' -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
On Mon, 2 Apr 2001, Andrei Zmievski wrote:
On Mon, 02 Apr 2001, Alexander Feldman wrote: Hi, These are the
results and questions from some tests I run yesterday on the last
4.0.5 release candidate. Note that all differences are from PHP
4.0.4pl1. 1. The function array_flip($array) puts one extra zero
byte at the end of each element in the return array thus making the
result non binary safe.
I've just fixed it in CVS.
Great.
3. The count_chars() function returns different result from the
4.0.4pl1 count_chars() function.
Examples?
Ok, now I analyzed the output more carefully - the problem had been in
4.0.4 - the count_chars function there doesn't create element for the byte
with value 255. This is fixed here - I do not expect problems with this
function (BTW, it doesn't seem to be widely used)...
Attached is a script that reproduces the difference.
-Andrei
"The only true currency in this bankrupt world is what we share with
each other when we're uncool." -- Lester Bangs, from the film 'Almost
Famous'
Thanks:
-- Alex
for ($i = 0; $i = 4; $i++) {
$res = count_chars("Mary had a little lamb and she loved it so.", $i);
if (is_array($res)) {
foreach ($res as $x =; $y)
print("$x($y) ");
print("\n");
} else {
if (4 == $i)
$res = addcslashes($res, "\0..\377");
print("$res\n");
}
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] PHP 4.0.5 Release Candidate testing
1. The function array_flip($array) puts one extra zero byte at the end of each element in the return array thus making the result non binary safe. I've just fixed it in CVS. How critical is this? does it need to also be in 4.0.5 (sorry Zeev ;)) James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
Andrei, Can you please merge this to 4.0.5. I think it should be in and we better release a final RC6. I think it's better to have another quick RC (I can roll it today or tomorrow) before we get 4.0.5 out of the door. Andi At 08:25 AM 4/2/2001 -0500, Andrei Zmievski wrote: On Mon, 02 Apr 2001, Alexander Feldman wrote: Hi, These are the results and questions from some tests I run yesterday on the last 4.0.5 release candidate. Note that all differences are from PHP 4.0.4pl1. 1. The function array_flip($array) puts one extra zero byte at the end of each element in the return array thus making the result non binary safe. I've just fixed it in CVS. 3. The count_chars() function returns different result from the 4.0.4pl1 count_chars() function. Examples? -Andrei "The only true currency in this bankrupt world is what we share with each other when we're uncool." -- Lester Bangs, from the film 'Almost Famous' -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
It's done. On Mon, 02 Apr 2001, Andi Gutmans wrote: Andrei, Can you please merge this to 4.0.5. I think it should be in and we better release a final RC6. I think it's better to have another quick RC (I can roll it today or tomorrow) before we get 4.0.5 out of the door. Andi -Andrei * Non-volatile, random-access, analog memory store... a book. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
Thanks! Does anyone else have any critical bug fixes which need to be in 4.0.5? (I mean critical ones and not huge patches). Andi At 11:17 AM 4/2/2001 -0500, Andrei Zmievski wrote: It's done. On Mon, 02 Apr 2001, Andi Gutmans wrote: Andrei, Can you please merge this to 4.0.5. I think it should be in and we better release a final RC6. I think it's better to have another quick RC (I can roll it today or tomorrow) before we get 4.0.5 out of the door. Andi -Andrei * Non-volatile, random-access, analog memory store... a book. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
Andi Gutmans wrote: Does anyone else have any critical bug fixes which need to be in 4.0.5? (I mean critical ones and not huge patches). Zeev's output buffering fix hasn't been committed yet; it's a one-line change, and it makes the transparent output compression stuff work. Does anyone have any objection to an MFH on the small Vary header patch also? It improves PHP's RFC2616 compliance, but it also unbreaks almost every web-cache, which rely on having it present for content-negotiated pages. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
Zeev's output buffering fix hasn't been committed yet; it's a one-line change, and it makes the transparent output compression stuff work. MFH it then and we can get 4.0.5 out the door ;) James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
At 05:37 PM 4/2/2001 +0100, Anil Madhavapeddy wrote: Andi Gutmans wrote: Does anyone else have any critical bug fixes which need to be in 4.0.5? (I mean critical ones and not huge patches). Zeev's output buffering fix hasn't been committed yet; it's a one-line change, and it makes the transparent output compression stuff work. I suggest you merge this into 4.0.5 because it seems to me that otherwise output buffering will be quite a mess without it. It would be a shame to release 4.0.5 without it. Does anyone have any objection to an MFH on the small Vary header patch also? It improves PHP's RFC2616 compliance, but it also unbreaks almost every web-cache, which rely on having it present for content-negotiated pages. Your fix looks OK but I'd like to hear the opinion of someone else who is more familiar with RFC2616. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] PHP 4.0.5 Release Candidate testing
At 03:18 PM 4/2/2001 +0100, James Moore wrote: 1. The function array_flip($array) puts one extra zero byte at the end of each element in the return array thus making the result non binary safe. I've just fixed it in CVS. How critical is this? does it need to also be in 4.0.5 (sorry Zeev ;)) Yes, I think it should be in 4.0.5 And the output buffering patch of Zeev should be in there too. Hopefully RC6 will be the last RC. Better another RC than a pl1. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
Andi Gutmans wrote: I suggest you merge this into 4.0.5 because it seems to me that otherwise output buffering will be quite a mess without it. It would be a shame to release 4.0.5 without it. Ok, done. Your fix looks OK but I'd like to hear the opinion of someone else who is more familiar with RFC2616. Hope I didn't jump the gun with the merge (read this mail right after the commit). Here is the relevant excerpt from the RFC: 13.6 Caching Negotiated Responses Use of server-driven content negotiation (section 12.1), as indicated by the presence of a Vary header field in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests. See section 14.44 for use of the Vary header field by servers. A server SHOULD use the Vary header field to inform a cache of what request-header fields were used to select among multiple representations of a cacheable response subject to server-driven negotiation. The set of header fields named by the Vary field value is known as the "selecting" request-headers. When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header field, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the selecting request-headers present in the new request match the corresponding stored request-headers in the original request. Note that the current PEAR implementation of HTTP::Compress sends exactly this Vary header also, and works great. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
