#39447 [Com]: Want to optionally handle apc_upload_progress variables using session variables
ID: 39447 Comment by: brandon at invisionpower dot com Reported By: krudtaa at yahoo dot com Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: 5.2.0 New Comment: I'm inclined to agree with the request, actually. The hooks are great. It's also great that APC provides a way to use them - but what about the thousands (millions?) of users on shared hosting who don't have control over their operating environment. One of my (many) projects that I'm a part of is a download management system, and of course as you can imagine an upload progress meter is among the top requested features. I've just implemented one for our next release utilizing APC, but I fear the number of users who will be able to actually utilize it are relatively low. It would be nice to see some sort of functionality within PHP itself (without the need for any extensions) to be able to utilize the hooks. Previous Comments: [2007-06-01 09:48:01] krudtaa at yahoo dot com Okay More specific request here: I would like to be able to use the upload hooks with other storage module(s) than APC. A storage module that are more commonly included in PHP installations than APC. I would like to see support for the upload hooks in these modules: -Files module ...and when that works, then why not also make it work against the -mm module Maybe, in near future, we can be able to reference a session variable in order to read the status from the upload! So, is there any PHP developer that will make sure this is done? And when can we expect to see it implemented? This year, next year, 5 years, ? [2007-05-29 07:49:42] krudtaa at yahoo dot com Using the word native was probably a miss... I try one more time: What I ment by native was this: Making it possible to use the new upload hooks without having to include extensions. Example: www.domeneshop.no offers usage of php. BUT THEY DO NOT OFFER USAGE OF APC, as well as many other. My point was that by incorporationg a method to use the new upload hooks without having to rely on some extensions that MANY do not include in their PHP installation, then many many more users of PHP could actually make use of the new (and VERY practical) upload hooks. And I suggested a way to make it work By using session variable to store the data regarding the upload progress, which would be accessible for practically all the PHP installations around (version dependant though). If you developers do not see this point then huhhh ... I give up. Why not make it as easy as possible for the users of PHP to be able to use the upload hooks, is beyond me. So come on, let the upload hooks be accessible as it is today, with the usage of extensions like APC AND also by using a SESSION variable And at last... If you developers are not willing to do this, what is your motivation for NOT doing it? Do you not want most users of PHP to be able to use the new upload hooks? What matters in the end, at least for me, is what I can offer my end-users. And beeing able to easily offer them a way to actually see in "real-time" the progress of the upload is a huge step in the right direction. But as it is now, it is just for the few "lucky" ones that are able to make use of APC I'm a little confused that there is so little interest in making these new upload hooks more accessible!!! Regards [2007-05-28 20:29:43] [EMAIL PROTECTED] >Is there any plans to support upload progress natively in PHP? Extensions are native to PHP. >The hooks are there, why not make it possible to use them >without any extensions? "Why not to make _everything_ possible without any extensions?" Because it does not make sense. [2007-05-28 13:17:57] krudtaa at yahoo dot com Hi. So, is there any chance to get this work without any extensions like APC in near future. Why not make the core PHP store the related data in a session variable, still using JSON? Is there any plans to support upload progress natively in PHP? The hooks are there, why not make it possible to use them without any extensions? [2006-11-11 22:35:05] [EMAIL PROTECTED] You are slightly confused here. What PHP 5.2 provides is a set of hooks that the various storage modules can hook into. It in no way calls anything in APC. It just so happens that APC was the first extension to add support for those hooks. The various other extensions that are capable of storing data each need to add support for these hooks. -
#40846 [Com]: pcre.backtrack_limit too restrictive
ID: 40846 Comment by: brandon at invisionpower dot com Reported By: crisp at xs4all dot nl Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 5.2.1 New Comment: Installations of 5.2 are causing this issue for us with relatively simple regex. Users can submit an arbitrary amount of data (I work on a bulletin board software) that is parsed out for bbcode tags. Even simple expressions are causing problems. $txt = preg_replace_callback( "#\[code\](.+?)\[/code\]#is", array( &$this, 'regex_code_tag' ), $txt ); var_dump( preg_last_error() ); The callback function is not being hit at all and the output is int(2) (backtrack limit hit). Increasing backtrack limit to 1,000,000 "resolves" the issue, but with shared hosting plans it's unrealistic to expect hosts to make php.ini changes to allow this. I agree with crisp - the limit in PHP should bet set to the internal PCRE options, with the php.ini settings allowing you to reduce them if you wish. PHP should not arbitrarily reduce them. Previous Comments: [2007-05-20 11:22:00] crisp at xs4all dot nl PHP 5.2.0 includes an update of the PCRE library (version 6.7), so some problems may not be totally due to the restrictive limits of the PCRE settings in PHP but could be a bug/regression in PCRE itself. PCRE has always been very poor in internal optimisation of expressions that contain look-aheads or look-behinds, especially when they are combined with some OR'ed subexpression. It's backtracking mechanism is quite simplistic and doesn't rule out execution paths that are sure not to result in a match - in fact, it doesn't have any sort of execution planner. [2007-05-20 11:09:08] tigr at mail15 dot com It is kinda strange: previous versions work pretty nice, swiftly executing all patterns. And in some situations (as I mentioned before) increasing recursion and backtrack limits just won't help. I suppose it's wrong behaviour. Also, note that examples are pretty short and simple. Increasing both limits to 1 000 000 does not help - just why? [2007-05-20 10:49:37] [EMAIL PROTECTED] we simply can't increase recursion limit or we risk segfaulting php. increase the backtrack limit is also risky, but is much safer (although regexes with much backtracking are usually not well written). I'll think more about this.. [2007-05-19 08:32:44] tigr at mail15 dot com Sorry, little mistake: expected result not 'replaced replaced replaced', but 'replaced replaced'. [2007-05-19 06:49:43] tigr at mail15 dot com For me this new behaviour have broken my templates system. While some of regexpes where simplified, others could not be done so. In some situations increasing these numbers of little help. For instance(the regexp was simplified greatly, in real-life application it is much more complex): Expected result - 'replaced replaced replaced'. Actual result - nothing, NULL returned, preg_last_error() shows that there is PREG_BACKTRACK_LIMIT_ERROR error. Also increasing backtrack limit leads to another error, PREG_RECURSION_LIMIT_ERROR. Increasing recursion limit leads to php hanging up. Changing first or second asterisk in pattern to plus sign immediately fixes the problem, but I need it in this way. Also, do you think that this is a correct behaviour? I thing there is a bug somewhere that way. However, this works pretty well on php 4.x, 5.x and even at 5.2.1 (at one of the hosts), but it does not work on my local php5.2.2 on WinXPsp2. 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/40846 -- Edit this bug report at http://bugs.php.net/?id=40846&edit=1
