ID: 27372
User updated by: php-bug-27372 at ryandesign dot com
-Reported By: php-bug-NOSPAM-2004 at ryandesign dot com
+Reported By: php-bug-27372 at ryandesign dot com
Status: Verified
Bug Type: *General Issues
Operating System: *
PHP Version: 5CVS, 4CVS (2004-04-07)
New Comment:
Based on the previous conversation in this bug I had been
under the impression that the new browscap parser had made
it into PHP 5.1 and 5.0, but I can find no trace of it in
5.1.0RC1. Today for the first time since 6 months I updated
my php_browscap with the one from Gary's site and PHP threw
a parse error, and I noticed that the two entries where the
browser glob contains square brackets throw the standard ini
parser for a loop. I sent Gary corrections for the
php_browscap that make it work with PHP (replace square
brackets with question marks) but the whole idea here is
that we want to have a parser that works with Gary's
standard files, so that we don't keep bugging him.
What was the response to the new browscap parser on the PHP
internals list? What would be required to get it committed
to 5.1 before it goes final? I'd be happy to test it on
Gary's files or evaluate the code or give a shot at
rewriting bits of it if there were any objections to the
original implementation.
I was so sure we had taken care of this last year. Please,
let's make sure it gets into PHP 5.1 and doesn't have to
wait until 5.2 or 6.0. Thanks.
Previous Comments:
------------------------------------------------------------------------
[2004-10-04 17:05:44] [EMAIL PROTECTED]
This would have to be caught during module start up, but
what should be done about it? Have the parser crap out and
stop processing when this happens, leaving an error
message in the logs or on stderr or whatever? Spit out a
warning but continue processing? What assumptions should
be made about the screwed up entry, should it just be
discarded?
This should probably be in it's own bug report, btw, this
is a seperate issue from the original report. (The new
parser fixes the original bug report, but not this issue,
which may or may not be fixed, as it's kind of a problem
with the ini file itself, akin to calling a function with
infinite recursion...)
J
------------------------------------------------------------------------
[2004-10-02 21:54:48] alexandre at alapetite dot remove dot net
Gary Keith has already (2004-10-02) kindly modified his browscap.ini in
order to prevent a specific crash about the Nutch browser. But the
browscap parser should anyway include a security: when one assign a
parent to the same parent in browscap.ini, there is an infinite loop
that should be prevented.
Example in browscap.ini:
[Nutch]
parent=Nutch
Then in a PHP script:
$browser=get_browser('Nutch');
Effect:
Infinite loop that takes 100% CPU forever.
------------------------------------------------------------------------
[2004-08-31 21:22:34] [EMAIL PROTECTED]
I posted this on internals but I should probably add it to
the bug report, too...
A patch for this against HEAD is available at
http://bugs.tutorbuddy.com/download.php/browscap.patch.tar.gz
It contains the new parser (which goes into ext/standard)
and updates to the makefiles for *ix and win32. I've
tested the patch on linux and win2k, and I'd like to
commit to HEAD for inclusion in 5.1. Backporting to 5.0
would be nice, too, if possible.
J
------------------------------------------------------------------------
[2004-02-26 18:32:25] php_bug_27372 at garykeith dot com
Hi, Derick.
Since there are so many people still using very early versions of 4.3.x
I know it will be a very long time before everyone upgrades to 5.* and
that means I'll be stuck in the same untenable situation I'm in right
now for a very long time.
Kindly remove the link to my website from your documentation page. It's
not fair to your users to refer them to a browscap.ini file that does
not work in PHP.
~gary.
------------------------------------------------------------------------
[2004-02-26 16:37:33] [EMAIL PROTECTED]
Hey,
there will be no back-port to PHP 4.3, as it involves writing a whole
new parser, which is simply something that should not go into a bug-fix
only branch (and it is also very unlikely that there will be a 4.3.6
anyway).
Now, for PHP 5 that is obviously not a problem and we'll have to write
a new parser for it, which is not an easy task, and that takes time
too. I can't not guarantee in which time frame that happens though.
Derick
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/27372
--
Edit this bug report at http://bugs.php.net/?id=27372&edit=1
