Req #62043 [Com]: new operator
Edit report at https://bugs.php.net/bug.php?id=62043&edit=1
ID: 62043
Comment by: reeze dot xia at gmail dot com
Reported by:piotrekz5 at wp dot pl
Summary:new operator
Status: Open
Type: Feature/Change Request
Package:PHP options/info functions
Operating System: any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Do you mean this operator?
$a = $a ?: "default value");
http://www.php.net/manual/en/language.operators.comparison.php#language.operators.
comparison.ternary
Previous Comments:
[2012-05-16 00:31:03] phpmpan at mpan dot pl
BEGIN CODE
function ifNull($var, $value, $null = NULL) {
return ($var !== $null)? $var : $value;
}
- END CODE -
Or even simpler to use and, unlike previous, working fine with undefined
variables:
BEGIN CODE
function unNull(&$var, $value, $null = NULL) {
if ($var === $null) {
$var = $value;
}
return $var;
}
- END CODE -
If we drop the last argument even multiple operands version can be achieved:
BEGIN CODE
function nonNull() {
return array_reduce(func_get_args(), function(&$a, $e) {
return ($a === NULL && $e !== NULL)? $e : $a;
});
}
- END CODE -
Any reason to not do this in userland?
[2012-05-15 23:23:20] piotrekz5 at wp dot pl
Description:
Hi,
Let's implement a new operator - '??' (used in c#).
The ?? operator is called the null-coalescing operator and is used to define a
default value. It returns the left-hand operand if the operand is not null;
otherwise it returns the right operand.
Test script:
---
example:
$var1 = null;
$var2 = null;
$var3 = $var1 ?? $var2; //$var3==null
$var4 = $var1 ?? 'default1'; //$var4=='default1'
$var5 = $var1 ?? $var2 ?? 'default2'; //$var5=='default2'
$var6 = $var2 ?? $var3 ?? $var4 ?? 'default3'; //$var6=='default1' since the
first non-null value is $var4=='default1'
--
Edit this bug report at https://bugs.php.net/bug.php?id=62043&edit=1
Req #52000 [Com]: Exception thrown in autload handler does not prevents other handlers from execu
Edit report at https://bugs.php.net/bug.php?id=52000&edit=1 ID: 52000 Comment by: reeze dot xia at gmail dot com Reported by:starach at gmail dot com Summary:Exception thrown in autload handler does not prevents other handlers from execu Status: Feedback Type: Feature/Change Request Package:SPL related Operating System: Windows XP SP3 PHP Version:5.3.2 Block user comment: N Private report: N New Comment: Hi, starach: This is not a bug, but a FEATURE :), it was intentional, please see: http://svn.php.net/viewvc?view=revision&revision=262515. thanks Previous Comments: [2010-06-05 15:59:13] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-06-05 15:51:34] starach at gmail dot com Description: If there are two class loaders registered second one will be executed even if we throw exception in first one. -- Edit this bug report at https://bugs.php.net/bug.php?id=52000&edit=1
[PHP-BUG] Req #62044 [NEW]: Short object syntax request
From:
Operating system:
PHP version: 5.4.3
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Short object syntax request
Description:
Thanks for short arrays syntax! :) Now it's a time to create short object
syntax for simple creatation of anonymous objects with custom fields. The
current shortest way is:
$obj = (object)['field1' => 'value1', 'field2' => 'value2'];
Think it isn't beautiful :) I suggest the following syntax similar to
JavaScript (which is very handly):
$obj = {{field1: 'value1', field2: 'value2'}};
or, if it possible, the same as JavaScript:
$obj = {field1: 'value1', field2: 'value2'};
--
Edit bug report at https://bugs.php.net/bug.php?id=62044&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62044&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62044&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62044&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62044&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62044&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62044&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62044&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62044&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62044&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62044&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62044&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62044&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62044&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62044&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62044&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62044&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62044&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62044&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62044&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62044&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62044&r=mysqlcfg
Req #62043 [Com]: new operator
Edit report at https://bugs.php.net/bug.php?id=62043&edit=1
ID: 62043
Comment by: phpmpan at mpan dot pl
Reported by:piotrekz5 at wp dot pl
Summary:new operator
Status: Open
Type: Feature/Change Request
Package:PHP options/info functions
Operating System: any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
BEGIN CODE
function ifNull($var, $value, $null = NULL) {
return ($var !== $null)? $var : $value;
}
- END CODE -
Or even simpler to use and, unlike previous, working fine with undefined
variables:
BEGIN CODE
function unNull(&$var, $value, $null = NULL) {
if ($var === $null) {
$var = $value;
}
return $var;
}
- END CODE -
If we drop the last argument even multiple operands version can be achieved:
BEGIN CODE
function nonNull() {
return array_reduce(func_get_args(), function(&$a, $e) {
return ($a === NULL && $e !== NULL)? $e : $a;
});
}
- END CODE -
Any reason to not do this in userland?
Previous Comments:
[2012-05-15 23:23:20] piotrekz5 at wp dot pl
Description:
Hi,
Let's implement a new operator - '??' (used in c#).
The ?? operator is called the null-coalescing operator and is used to define a
default value. It returns the left-hand operand if the operand is not null;
otherwise it returns the right operand.
Test script:
---
example:
$var1 = null;
$var2 = null;
$var3 = $var1 ?? $var2; //$var3==null
$var4 = $var1 ?? 'default1'; //$var4=='default1'
$var5 = $var1 ?? $var2 ?? 'default2'; //$var5=='default2'
$var6 = $var2 ?? $var3 ?? $var4 ?? 'default3'; //$var6=='default1' since the
first non-null value is $var4=='default1'
--
Edit this bug report at https://bugs.php.net/bug.php?id=62043&edit=1
[PHP-BUG] Req #62043 [NEW]: new operator
From: Operating system: any PHP version: Irrelevant Package: PHP options/info functions Bug Type: Feature/Change Request Bug description:new operator Description: Hi, Let's implement a new operator - '??' (used in c#). The ?? operator is called the null-coalescing operator and is used to define a default value. It returns the left-hand operand if the operand is not null; otherwise it returns the right operand. Test script: --- example: $var1 = null; $var2 = null; $var3 = $var1 ?? $var2; //$var3==null $var4 = $var1 ?? 'default1'; //$var4=='default1' $var5 = $var1 ?? $var2 ?? 'default2'; //$var5=='default2' $var6 = $var2 ?? $var3 ?? $var4 ?? 'default3'; //$var6=='default1' since the first non-null value is $var4=='default1' -- Edit bug report at https://bugs.php.net/bug.php?id=62043&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62043&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62043&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62043&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62043&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62043&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62043&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62043&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62043&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62043&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62043&r=support Expected behavior: https://bugs.php.net/fix.php?id=62043&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62043&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62043&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62043&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62043&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62043&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62043&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62043&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62043&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62043&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62043&r=mysqlcfg
Bug #62032 [Opn]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 User updated by:iamcraigcampbell at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: @anon I agree with many of your sentiments :) Just wanted to point out one thing. The issue of unclosed script tags or other tags would not be a problem assuming the output is escaped which it should be. Therefore if you had "Well I can understand stripping it if there is a closing > somewhere, but if >it is a < that is not followed by a matching > then it should be allowed in the string and not stripped. In that case: (1) Unclosed tags will eat extra page content, breaking page layout. (2) Pages consist of many echo statements. By your logic, "", we need to implement a delayed-choice quantum eraser to make all the parallel universes in which the earlier echo statement occurred cease to exist. >I think it is more expected behavior to display this string as "This is NOT >good!". No. Display what users type. Don't delete text from their posts based on the quirks of what just happens to be the underlying display format on a particular day. Suppose your hypothetical forum also displays posts in another format, e.g., it has a Flash or iPhone-based app, or it tweets posts, or a few years from now we're all using a completely different markup language. Should it then also strip HTML-like tags from all text in perpetuity from all media just because HTML happened to be a relevant format to someone somewhere once upon a time, or should user-submitted text throw integrity to the wind and change depending on what kind of device someone is attempting to use to view it, whether or not that device's markup was invented when the post was made? What if someone is trying to use text that legitimately resembles an HTML tag (it happens), or, more likely, they're trying to quote or talk about HTML -- no filter can handle this. No no no no no. Display what they type and don't confuse the poor souls. I.e., use htmlspecialchars() if outputting to HTML; or if not, use whatever other escaping method is appropriate to the particular output format that still preserves the integrity of the user-typed text in that format, while making exception for the formatting markup that is legitimately supported and documented to be supported by the forum, such as markdown or bbcode syntax (and probably not HTML, since besides the fact that HTML is ugly and over-complicated for most forum post needs, strip_tags with an allowed tags parameter is the most dangerous of the lot and allows blatant abuse via attributes). And don't get me started on entities. tl;dr: no amount of wrapping it in flashy filter functions changes the fact that strip_tags confuses countless souls, is brain-damaged, and ought to be deprecated to death. [2012-05-15 15:06:26] iamcraigcampbell at gmail dot com @pajoye I agree with you, but there is a use case that encoding will not solve. Let's say there is a forum where users are posting. If the user posts: "This is NOT good!" and the tags get encoded then that means the HTML tags will be displayed in the forum as plain text. I think it is more expected behavior to display this string as "This is NOT good!". So one option would be encoding the < only if it is not followed by a > but that is a lot of extra work to figure that out. At the end of the day the point is that no matter how you look at it I still think this is a bug. $string = 'This is true: 2<5'; strip_tags($string); and filter_var($string, FILTER_SANITIZE_STRING); Should not strip out <5 since that is not an HTML tag. [2012-05-15 14:51:09] aleksey dot v dot korzun at gmail dot com How is stripping anything after < with a space is a valid operation? That seems like a lazy man's html stripper. Let's just blindly strip everything that can possibly be made into an html tag of any sort. Not. [2012-05-15 14:49:02] paj...@php.net > or < should be encoded then, see http://www.php.net/manual/en/filter.filters.sanitize.php btw, any option should be added using the option array or defaults, as it is the case already. [2012-05-15 14:45:27] iamcraigcampbell at gmail dot com So in that case I think strip_tags and filter_var are both broken. In this context: "It is true that 5<10" "It is true that 5 < 10" Neither of th
Bug #62032 [Com]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 Comment by: anon at anon dot anon Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: Well I never heard of this "SANITIZE_STRING" filter before, but it looks just as retarded as it sounds, and about as retarded as strip_tags. 99.99% of the time, strip_tags just should not be used at all because it's horribly broken. The real bugs are (1) strip_tags exists, and (2) that PHP should imply that any kind of magical all-purpose "string sanitization" process could exist. @iamcraigcampbell: >Well I can understand stripping it if there is a closing > somewhere, but if >it is a < that is not followed by a matching > then it should be allowed in the string and not stripped. In that case: (1) Unclosed tags will eat extra page content, breaking page layout. (2) Pages consist of many echo statements. By your logic, "", we need to implement a delayed-choice quantum eraser to make all the parallel universes in which the earlier echo statement occurred cease to exist. >I think it is more expected behavior to display this string as "This is NOT >good!". No. Display what users type. Don't delete text from their posts based on the quirks of what just happens to be the underlying display format on a particular day. Suppose your hypothetical forum also displays posts in another format, e.g., it has a Flash or iPhone-based app, or it tweets posts, or a few years from now we're all using a completely different markup language. Should it then also strip HTML-like tags from all text in perpetuity from all media just because HTML happened to be a relevant format to someone somewhere once upon a time, or should user-submitted text throw integrity to the wind and change depending on what kind of device someone is attempting to use to view it, whether or not that device's markup was invented when the post was made? What if someone is trying to use text that legitimately resembles an HTML tag (it happens), or, more likely, they're trying to quote or talk about HTML -- no filter can handle this. No no no no no. Display what they type and don't confuse the poor souls. I.e., use htmlspecialchars() if outputting to HTML; or if not, use whatever other escaping method is appropriate to the particular output format that still preserves the integrity of the user-typed text in that format, while making exception for the formatting markup that is legitimately supported and documented to be supported by the forum, such as markdown or bbcode syntax (and probably not HTML, since besides the fact that HTML is ugly and over-complicated for most forum post needs, strip_tags with an allowed tags parameter is the most dangerous of the lot and allows blatant abuse via attributes). And don't get me started on entities. tl;dr: no amount of wrapping it in flashy filter functions changes the fact that strip_tags confuses countless souls, is brain-damaged, and ought to be deprecated to death. Previous Comments: [2012-05-15 15:06:26] iamcraigcampbell at gmail dot com @pajoye I agree with you, but there is a use case that encoding will not solve. Let's say there is a forum where users are posting. If the user posts: "This is NOT good!" and the tags get encoded then that means the HTML tags will be displayed in the forum as plain text. I think it is more expected behavior to display this string as "This is NOT good!". So one option would be encoding the < only if it is not followed by a > but that is a lot of extra work to figure that out. At the end of the day the point is that no matter how you look at it I still think this is a bug. $string = 'This is true: 2<5'; strip_tags($string); and filter_var($string, FILTER_SANITIZE_STRING); Should not strip out <5 since that is not an HTML tag. [2012-05-15 14:51:09] aleksey dot v dot korzun at gmail dot com How is stripping anything after < with a space is a valid operation? That seems like a lazy man's html stripper. Let's just blindly strip everything that can possibly be made into an html tag of any sort. Not. [2012-05-15 14:49:02] paj...@php.net > or < should be encoded then, see http://www.php.net/manual/en/filter.filters.sanitize.php btw, any option should be added using the option array or defaults, as it is the case already. [2012-05-15 14:45:27] ia
Bug #53881 [Wfx]: nl2.php.net IPv6 broken
Edit report at https://bugs.php.net/bug.php?id=53881&edit=1 ID: 53881 Updated by: danbr...@php.net Reported by:tozz at kijkt dot tv Summary:nl2.php.net IPv6 broken Status: Wont fix Type: Bug Package:Unknown/Other Function Operating System: Irrelevant PHP Version:Irrelevant Assigned To:danbrown Block user comment: N Private report: N New Comment: While I do appreciate your suggestions, this is still not something we're going to fix at this stage. Also, sometime after you originally submitted this bug, nl2.php.net was removed from our network. Finally, for anyone using IPv6 as their exclusive (or even primary) network routing, I'm sure there are far greater issues than an occasionally-broken PHP mirror. Again, we will address this at a point, just not this point. Thanks again. Previous Comments: [2012-05-15 21:11:39] tozz at kijkt dot tv I understand IPv6 is not a requirement. However, some mirrors do have an -Address but fail to provide working connectivity to that address. The net result is that the PHP website is down for anyone with IPv6 connectivity if he/she is redirected to a mirror with bad IPv6 connectivity. So either the records should be removed or PHP.net should require mirrors to have decent IPv6 connectivity. [2012-05-15 21:04:28] danbr...@php.net At this time, we do not require IPv6 capabilities on official php.net mirrors. We will begin to phase-in this requirement once the majority of the ISPs and NOCs which host the official mirrors have IPv6 support permanently enabled, and expect to see an increase in that number on 6 June, 2012 (World IPv6 Day), as is the norm each year. Thank you for submitting this report. [2011-01-30 00:04:33] tozz at kijkt dot tv IPv6 traceroute to the SinnerG broken mirror (to indicate its not a routing issue on my side): # traceroute6 2a00:f10:111::1337:1000 traceroute to 2a00:f10:111::1337:1000 (2a00:f10:111::1337:1000) from 2a01:1b0:7999:402::3, 30 hops max, 24 byte packets 1 2a01:1b0:7999:402::e (2a01:1b0:7999:402::e) 0.854 ms 0.952 ms 0.99 ms 2 2a01:1b0:2:6::1 (2a01:1b0:2:6::1) 4.985 ms 4.979 ms 4.991 ms 3 bit.telecity2.nlsix.net (2001:7f8:13::a501:2859:2) 5.987 ms 5.968 ms 5.99 ms 4 tengig-1-1-0.bcr2.ams02.nl.as25525.net (2001:7f8:1::a502:5525:1) 6.987 ms 5.974 ms 5.988 ms 5 2001:16f8:bb2:197:0:a504:8635:2 (2001:16f8:bb2:197:0:a504:8635:2) 6.989 ms 7.972 ms 6.99 ms 6 2a00:f10:10a:2::4 (2a00:f10:10a:2::4) 6.987 ms 6.977 ms 6.99 ms 7 2a00:f10:10a:2::4 (2a00:f10:10a:2::4) 3010.85 ms !H 3010.81 ms !H 3007.83 ms !H [2011-01-29 23:58:16] tozz at kijkt dot tv Description: nl.php.net has some records which are very often broken (currently 2 out of 3 are broken). From what I've read PHP checks its mirrors on regular intervals, but apparently does not check if both IP4 and IP6 work. The lack of this IPv6 check causes the PHP website to load very slow as it waits a few seconds for a timeout on v6 and then falls back to v4. Perhaps this check can be extended to also check for correct IPv6 function and remove the mirror if its IPv6 connectivity is broken. Test script: --- # date Sat Jan 29 23:20:16 CET 2011 # telnet -6 nl2.php.net 80 Trying 2a01:448:1::1036:64:164... telnet: Unable to connect to remote host: Connection refused # telnet -6 nl.php.net 80 Trying 2a00:f10:111::1337:1000... telnet: Unable to connect to remote host: No route to host Expected result: I would expect that the PHP mirror check removes mirrors that have broken v6 connectivity. -- Edit this bug report at https://bugs.php.net/bug.php?id=53881&edit=1
Bug #53881 [Wfx]: nl2.php.net IPv6 broken
Edit report at https://bugs.php.net/bug.php?id=53881&edit=1 ID: 53881 User updated by:tozz at kijkt dot tv Reported by:tozz at kijkt dot tv Summary:nl2.php.net IPv6 broken Status: Wont fix Type: Bug Package:Unknown/Other Function Operating System: Irrelevant PHP Version:Irrelevant Assigned To:danbrown Block user comment: N Private report: N New Comment: I understand IPv6 is not a requirement. However, some mirrors do have an -Address but fail to provide working connectivity to that address. The net result is that the PHP website is down for anyone with IPv6 connectivity if he/she is redirected to a mirror with bad IPv6 connectivity. So either the records should be removed or PHP.net should require mirrors to have decent IPv6 connectivity. Previous Comments: [2012-05-15 21:04:28] danbr...@php.net At this time, we do not require IPv6 capabilities on official php.net mirrors. We will begin to phase-in this requirement once the majority of the ISPs and NOCs which host the official mirrors have IPv6 support permanently enabled, and expect to see an increase in that number on 6 June, 2012 (World IPv6 Day), as is the norm each year. Thank you for submitting this report. [2011-01-30 00:04:33] tozz at kijkt dot tv IPv6 traceroute to the SinnerG broken mirror (to indicate its not a routing issue on my side): # traceroute6 2a00:f10:111::1337:1000 traceroute to 2a00:f10:111::1337:1000 (2a00:f10:111::1337:1000) from 2a01:1b0:7999:402::3, 30 hops max, 24 byte packets 1 2a01:1b0:7999:402::e (2a01:1b0:7999:402::e) 0.854 ms 0.952 ms 0.99 ms 2 2a01:1b0:2:6::1 (2a01:1b0:2:6::1) 4.985 ms 4.979 ms 4.991 ms 3 bit.telecity2.nlsix.net (2001:7f8:13::a501:2859:2) 5.987 ms 5.968 ms 5.99 ms 4 tengig-1-1-0.bcr2.ams02.nl.as25525.net (2001:7f8:1::a502:5525:1) 6.987 ms 5.974 ms 5.988 ms 5 2001:16f8:bb2:197:0:a504:8635:2 (2001:16f8:bb2:197:0:a504:8635:2) 6.989 ms 7.972 ms 6.99 ms 6 2a00:f10:10a:2::4 (2a00:f10:10a:2::4) 6.987 ms 6.977 ms 6.99 ms 7 2a00:f10:10a:2::4 (2a00:f10:10a:2::4) 3010.85 ms !H 3010.81 ms !H 3007.83 ms !H [2011-01-29 23:58:16] tozz at kijkt dot tv Description: nl.php.net has some records which are very often broken (currently 2 out of 3 are broken). From what I've read PHP checks its mirrors on regular intervals, but apparently does not check if both IP4 and IP6 work. The lack of this IPv6 check causes the PHP website to load very slow as it waits a few seconds for a timeout on v6 and then falls back to v4. Perhaps this check can be extended to also check for correct IPv6 function and remove the mirror if its IPv6 connectivity is broken. Test script: --- # date Sat Jan 29 23:20:16 CET 2011 # telnet -6 nl2.php.net 80 Trying 2a01:448:1::1036:64:164... telnet: Unable to connect to remote host: Connection refused # telnet -6 nl.php.net 80 Trying 2a00:f10:111::1337:1000... telnet: Unable to connect to remote host: No route to host Expected result: I would expect that the PHP mirror check removes mirrors that have broken v6 connectivity. -- Edit this bug report at https://bugs.php.net/bug.php?id=53881&edit=1
[PHP-BUG] Bug #62042 [NEW]: Fatal error when merging files due to class/function/symbol name collision
From:
Operating system: All
PHP version: 5.3.13
Package: Unknown/Other Function
Bug Type: Bug
Bug description:Fatal error when merging files due to class/function/symbol
name collision
Description:
These two namespaces work as expected when in two separate files, and when
included together at runtime work as expected as well, but once they're
merged
in the same file they result in a Fatal Error:
namespace Foo {
class Bar {}
}
namespace Foo {
use Bar;
}
Fatal error: Cannot use Bar as Bar because the name is already in use.
I understand this behavior was introduced with good intentions, but all it
does
is break working code when files are merged together. The alternative
namespace
construct was introduced specifically to support merging of multiple files
together without side effects, and this is such a side effect.
Expected result:
I expect that "use" statements should override default resolutions, and no
Fatal
Error should be produced (the EXACT behavior we have right now when the
above is
spread in two files which are required() at runtime).
Actual result:
--
Fatal Error when merging code.
--
Edit bug report at https://bugs.php.net/bug.php?id=62042&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62042&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62042&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62042&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62042&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62042&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62042&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62042&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62042&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62042&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62042&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62042&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62042&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62042&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62042&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62042&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62042&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62042&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62042&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62042&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62042&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62042&r=mysqlcfg
Bug #53881 [Opn->Wfx]: nl2.php.net IPv6 broken
Edit report at https://bugs.php.net/bug.php?id=53881&edit=1 ID: 53881 Updated by: danbr...@php.net Reported by:tozz at kijkt dot tv Summary:nl2.php.net IPv6 broken -Status: Open +Status: Wont fix Type: Bug Package:Unknown/Other Function Operating System: Irrelevant PHP Version:Irrelevant -Assigned To: +Assigned To:danbrown Block user comment: N Private report: N New Comment: At this time, we do not require IPv6 capabilities on official php.net mirrors. We will begin to phase-in this requirement once the majority of the ISPs and NOCs which host the official mirrors have IPv6 support permanently enabled, and expect to see an increase in that number on 6 June, 2012 (World IPv6 Day), as is the norm each year. Thank you for submitting this report. Previous Comments: [2011-01-30 00:04:33] tozz at kijkt dot tv IPv6 traceroute to the SinnerG broken mirror (to indicate its not a routing issue on my side): # traceroute6 2a00:f10:111::1337:1000 traceroute to 2a00:f10:111::1337:1000 (2a00:f10:111::1337:1000) from 2a01:1b0:7999:402::3, 30 hops max, 24 byte packets 1 2a01:1b0:7999:402::e (2a01:1b0:7999:402::e) 0.854 ms 0.952 ms 0.99 ms 2 2a01:1b0:2:6::1 (2a01:1b0:2:6::1) 4.985 ms 4.979 ms 4.991 ms 3 bit.telecity2.nlsix.net (2001:7f8:13::a501:2859:2) 5.987 ms 5.968 ms 5.99 ms 4 tengig-1-1-0.bcr2.ams02.nl.as25525.net (2001:7f8:1::a502:5525:1) 6.987 ms 5.974 ms 5.988 ms 5 2001:16f8:bb2:197:0:a504:8635:2 (2001:16f8:bb2:197:0:a504:8635:2) 6.989 ms 7.972 ms 6.99 ms 6 2a00:f10:10a:2::4 (2a00:f10:10a:2::4) 6.987 ms 6.977 ms 6.99 ms 7 2a00:f10:10a:2::4 (2a00:f10:10a:2::4) 3010.85 ms !H 3010.81 ms !H 3007.83 ms !H [2011-01-29 23:58:16] tozz at kijkt dot tv Description: nl.php.net has some records which are very often broken (currently 2 out of 3 are broken). From what I've read PHP checks its mirrors on regular intervals, but apparently does not check if both IP4 and IP6 work. The lack of this IPv6 check causes the PHP website to load very slow as it waits a few seconds for a timeout on v6 and then falls back to v4. Perhaps this check can be extended to also check for correct IPv6 function and remove the mirror if its IPv6 connectivity is broken. Test script: --- # date Sat Jan 29 23:20:16 CET 2011 # telnet -6 nl2.php.net 80 Trying 2a01:448:1::1036:64:164... telnet: Unable to connect to remote host: Connection refused # telnet -6 nl.php.net 80 Trying 2a00:f10:111::1337:1000... telnet: Unable to connect to remote host: No route to host Expected result: I would expect that the PHP mirror check removes mirrors that have broken v6 connectivity. -- Edit this bug report at https://bugs.php.net/bug.php?id=53881&edit=1
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556&edit=1 ID: 18556 Comment by: inet dot alper at gmail dot com Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:dmitry Block user comment: N Private report: N New Comment: https://github.com/php/php-src/pull/79 this patch does not break other locales, check it out. Previous Comments: [2012-05-05 15:33:55] wim at powerassist dot nl Sorry, I was to quick to comment. I see that there's an internal mailing going on. [2012-05-04 19:10:58] wim at powerassist dot nl Why is this bug still not fixed? Not only class names are affected but function names aswell: [2011-12-07 20:13:24] cankoy at ymail dot com > This will probably break a lot of existing PHP Code. Existing code is already broken for those suffering from this problem, don't you get it? I'm not suggesting a permanent turn-off, I'm suggesting a command-line option/a php.ini directive/whatever fits the design of Php engine to implement this as an option. > Why not performing the lookup case-sensitive and if not found fall back to > case-insensitive? And if found case-insensitive throw a deprecation warning. You're suggesting more ceremony, where I suggest optionally skipping a ceremony. Php is an interpreter, performance is important. [2011-12-07 20:01:07] gerd dot katzenbeisser at gmail dot com This will probably break a lot of existing PHP Code. Why not performing the lookup case-sensitive and if not found fall back to case-insensitive? And if found case- insensitive throw a deprecation warning. [2011-12-07 18:01:37] cankoy at ymail dot com This, practically, can't be fixed. Mainly because there's no way to know if 'I' is uppercase of 'i' or 'ı' since there's not a separate place for Turkish 'I' in code tables. The same holds for 'i' (can't be known if it's lowercase of 'I' or 'İ'). I told 2 years ago and will say it again: PHP should provide a way to turn off case-insensitive function/class name lookup. No good programmer uses this Basic language feature since identifiers are case-sensitive in all real languages like Python, Ruby, C#, Java. 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 https://bugs.php.net/bug.php?id=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556&edit=1
[PHP-BUG] Bug #62041 [NEW]: Fails when recursive group comes before reference
From:
Operating system: Windows Vista
PHP version: 5.4.3
Package: PCRE related
Bug Type: Bug
Bug description:Fails when recursive group comes before reference
Description:
When the recursive subpattern is captured after it is referenced:
(?2)?::(?>((?1)(?>:(?1)){0,4}):)?
It works fine. But when the capture comes before the reference it doesn't:
((?1)(?>:(?1)){0,4})?::(?>(?2):)?
The problem is the final ":" as other characters work fine. Replacing it
with "\:"
or "[:]" does not help.
Test script:
---
// Test 1
preg_match('/^(?>([a-f0-9]{1,4})(?>:(?1)){5}:|(?!(?:.*[a-f0-9]:){6,})(?2)?::(?>((?1)(?>:(?1)){0,4}):)?)(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?>\.(?3)){3}$/iD',
'0:0:0:0::0:255.255.255.255');
// Test 2
preg_match('/^(?>([a-f0-9]{1,4})(?>:(?1)){5}:|(?!(?:.*[a-f0-9]:){6,})((?1)(?>:(?1)){0,4})?::(?>(?2):)?)(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?>\.(?3)){3}$/iD',
'0:0:0:0::0:255.255.255.255');
// Test 3
preg_match('/^(?>([a-f0-9]{1,4})(?>:(?1)){5}:|(?!(?:.*[a-f0-9]:){6,})((?1)(?>:(?1)){0,4})?::(?>(?2)!)?)(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?>\.(?3)){3}$/iD',
'0:0:0:0::0!255.255.255.255');
Expected result:
// Test 1
int(1)
// Test 2
int(1)
// Test 3
int(1)
Actual result:
--
// Test 1
int(1)
// Test 2
int(0)
// Test 3
int(1)
--
Edit bug report at https://bugs.php.net/bug.php?id=62041&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62041&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62041&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62041&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62041&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62041&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62041&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62041&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62041&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62041&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62041&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62041&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62041&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62041&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62041&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62041&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62041&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62041&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62041&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62041&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62041&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62041&r=mysqlcfg
Bug #61777 [Com]: Cannot bind parameters with pdo_odbc and SQL Server Native Client 11.0
Edit report at https://bugs.php.net/bug.php?id=61777&edit=1
ID: 61777
Comment by: burnhamrobertp at gmail dot com
Reported by:frozen at frozen-solid dot net
Summary:Cannot bind parameters with pdo_odbc and SQL Server
Native Client 11.0
Status: Open
Type: Bug
Package:PDO related
Operating System: Ubuntu 12.04
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Debian Squeeze 2.6.32-5-amd64
PHP 5.3.3 (also reproducible under PHP 5.4.0-3)
The test case and error information are exactly the same.
Previous Comments:
[2012-04-19 18:45:03] frozen at frozen-solid dot net
Description:
When trying to bind parameters to a prepared statement, bindValue() and
bindParam() both return false with the error code HY004, [SQL Server Native
Client
11.0]Invalid SQL data type (SQLBindParameter[0] at /build/buildd/php5-
5.3.10/ext/pdo_odbc/odbc_stmt.c:379)
It does not matter whether you pass in PDO::PARAM_STR or PARAM_INT or no data
type
specification, the error is the same every time.
Using parameters with odbc_connect() and odbc_prepare() work as expected, so
the
issue is directly related to PDO, not to ODBC or Microsoft's driver.
Test script:
---
$db = new PDO('odbc:sqltest', 'wwwuser', 'btsb');
$strSql = 'select top 10 * from oltmaster where titleno = :no';
$q = $db->prepare($strSql);
var_dump($q->bindValue(':no', '029803'));
var_dump($q->errorInfo());
Expected result:
boolean true
array
0 => string '' (length=0)
1 => int 0
2 => string ' ((null)[0] at (null):0)' (length=24)
3 => string '' (length=0)
Actual result:
--
boolean false
array
0 => string 'HY004' (length=5)
1 => int 0
2 => string '[Microsoft][SQL Server Native Client 11.0]Invalid SQL data type
(SQLBindParameter[0] at
/build/buildd/php5-5.3.10/ext/pdo_odbc/odbc_stmt.c:379)'
(length=143)
3 => string 'HY004' (length=5)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61777&edit=1
Bug #62037 [Opn->Fbk]: .user.ini ignores open_basedir parameter
Edit report at https://bugs.php.net/bug.php?id=62037&edit=1 ID: 62037 Updated by: s...@php.net Reported by:karlis dot kisis at gmail dot com Summary:.user.ini ignores open_basedir parameter -Status: Open +Status: Feedback Type: Bug Package:Safe Mode/open_basedir Operating System: CentOS 6.2 x86_64 PHP Version:5.3.13 Block user comment: N Private report: N Previous Comments: [2012-05-15 15:17:13] reeze dot xia at gmail dot com Please refer: http://cn.php.net/manual/en/ini.core.php#ini.open-basedir âAs of PHP 5.3.0 open_basedir can be tightened at run-timeâ This means you can only make the path more deep but can't move back. if not there will be security problem. Maybe this is your problem [2012-05-15 15:01:40] karlis dot kisis at gmail dot com turns out that if the master value for open_basedir is None, then .user.ini value works! seems that .user.ini cannot override the master value from php.ini if open_basedir is defined. still a bug in my opinion. [2012-05-15 14:33:52] karlis dot kisis at gmail dot com Description: open_basedir parameter is ignored in .user.ini: max_input_time = 333 open_basedir = "/home" display_errors = On include_path = "/home" the rest of the parameters from above work fine. php is run as fcgi on apache 2.2.22 with mod_fcgid.c. according to the docs, open_basedir should be configurable anywhere since version 5.3 Test script: --- changed parameters are shown in phpinfo(), except open_basedir which remains unchanged. Expected result: open_basedir setting from .user.ini to be in effect. -- Edit this bug report at https://bugs.php.net/bug.php?id=62037&edit=1
Bug #62039 [Opn->Nab]: When multiple cookies are received, $Version=0 is badly concatened
Edit report at https://bugs.php.net/bug.php?id=62039&edit=1 ID: 62039 Updated by: s...@php.net Reported by:laurent dot perez at backelite dot com Summary:When multiple cookies are received, $Version=0 is badly concatened -Status: Open +Status: Not a bug Type: Bug Package:HTTP related -Operating System: PHP 5.3.6-13ubuntu3.7 +Operating System: Linux -PHP Version:master-Git-2012-05-15 (Git) +PHP Version:PHP 5.3.6-13ubuntu3.7 Block user comment: N Private report: N New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Please reopen if it occurs in a recent version of PHP. Previous Comments: [2012-05-15 16:11:11] laurent dot perez at backelite dot com Description: Hi I'm sending the following cookies to a PHP 5.3.6-13ubuntu3.7 page : >> "Cookie: $Version=0; applicookie=monappli[\r][\n]" >> "Cookie: $Version=0; monautrecookie=autrevaleur[\r][\n]" When I dump them using print_r($_COOKIE);, the value of the first one (applicookie) gets concatenated with a comma plus $Version=0 string : << "[applicookie] => monappli, $Version=0[\n]" << "[monautrecookie] => autrevaleur[\n]" It looks like a concatenation bug. The value of applicookie should not be modified. Test script: --- Get Firebug, install Firecookie, forge two cookies as HttpOnly, send them, will display a wrong value for the first one received. Expected result: Unmodified cookie values Actual result: -- The first cookie value gets concatenated with comma + $Version=0 string -- Edit this bug report at https://bugs.php.net/bug.php?id=62039&edit=1
[PHP-BUG] Bug #62039 [NEW]: When multiple cookies are received, $Version=0 is badly concatened
From: Operating system: PHP 5.3.6-13ubuntu3.7 PHP version: master-Git-2012-05-15 (Git) Package: HTTP related Bug Type: Bug Bug description:When multiple cookies are received, $Version=0 is badly concatened Description: Hi I'm sending the following cookies to a PHP 5.3.6-13ubuntu3.7 page : >> "Cookie: $Version=0; applicookie=monappli[\r][\n]" >> "Cookie: $Version=0; monautrecookie=autrevaleur[\r][\n]" When I dump them using print_r($_COOKIE);, the value of the first one (applicookie) gets concatenated with a comma plus $Version=0 string : << "[applicookie] => monappli, $Version=0[\n]" << "[monautrecookie] => autrevaleur[\n]" It looks like a concatenation bug. The value of applicookie should not be modified. Test script: --- Get Firebug, install Firecookie, forge two cookies as HttpOnly, send them, will display a wrong value for the first one received. Expected result: Unmodified cookie values Actual result: -- The first cookie value gets concatenated with comma + $Version=0 string -- Edit bug report at https://bugs.php.net/bug.php?id=62039&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62039&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62039&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62039&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62039&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62039&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62039&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62039&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62039&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62039&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62039&r=support Expected behavior: https://bugs.php.net/fix.php?id=62039&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62039&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62039&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62039&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62039&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62039&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62039&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62039&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62039&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62039&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62039&r=mysqlcfg
[PHP-BUG] Bug #62038 [NEW]: apache2 + fpm is incompatible with mod_cache, mod_mem_cache
From: Operating system: Linux PHP version: 5.3.13 Package: FPM related Bug Type: Bug Bug description:apache2 + fpm is incompatible with mod_cache, mod_mem_cache Description: when you install apache2 and configure php5-fpm and now so execute a2enmod mem_cache modul will be loaded but apache cache didn't work with FPM (all request will be handeled by FPM... none where use mem_cache) Test script: --- after setup try this -- Edit bug report at https://bugs.php.net/bug.php?id=62038&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62038&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62038&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62038&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62038&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62038&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62038&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62038&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62038&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62038&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62038&r=support Expected behavior: https://bugs.php.net/fix.php?id=62038&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62038&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62038&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62038&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62038&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62038&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62038&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62038&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62038&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62038&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62038&r=mysqlcfg
Bug #62037 [Com]: .user.ini ignores open_basedir parameter
Edit report at https://bugs.php.net/bug.php?id=62037&edit=1 ID: 62037 Comment by: reeze dot xia at gmail dot com Reported by:karlis dot kisis at gmail dot com Summary:.user.ini ignores open_basedir parameter Status: Open Type: Bug Package:Safe Mode/open_basedir Operating System: CentOS 6.2 x86_64 PHP Version:5.3.13 Block user comment: N Private report: N New Comment: Please refer: http://cn.php.net/manual/en/ini.core.php#ini.open-basedir âAs of PHP 5.3.0 open_basedir can be tightened at run-timeâ This means you can only make the path more deep but can't move back. if not there will be security problem. Maybe this is your problem Previous Comments: [2012-05-15 15:01:40] karlis dot kisis at gmail dot com turns out that if the master value for open_basedir is None, then .user.ini value works! seems that .user.ini cannot override the master value from php.ini if open_basedir is defined. still a bug in my opinion. [2012-05-15 14:33:52] karlis dot kisis at gmail dot com Description: open_basedir parameter is ignored in .user.ini: max_input_time = 333 open_basedir = "/home" display_errors = On include_path = "/home" the rest of the parameters from above work fine. php is run as fcgi on apache 2.2.22 with mod_fcgid.c. according to the docs, open_basedir should be configurable anywhere since version 5.3 Test script: --- changed parameters are shown in phpinfo(), except open_basedir which remains unchanged. Expected result: open_basedir setting from .user.ini to be in effect. -- Edit this bug report at https://bugs.php.net/bug.php?id=62037&edit=1
Bug #62032 [Com]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 Comment by: iamcraigcampbell at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: @pajoye I agree with you, but there is a use case that encoding will not solve. Let's say there is a forum where users are posting. If the user posts: "This is NOT good!" and the tags get encoded then that means the HTML tags will be displayed in the forum as plain text. I think it is more expected behavior to display this string as "This is NOT good!". So one option would be encoding the < only if it is not followed by a > but that is a lot of extra work to figure that out. At the end of the day the point is that no matter how you look at it I still think this is a bug. $string = 'This is true: 2<5'; strip_tags($string); and filter_var($string, FILTER_SANITIZE_STRING); Should not strip out <5 since that is not an HTML tag. Previous Comments: [2012-05-15 14:51:09] aleksey dot v dot korzun at gmail dot com How is stripping anything after < with a space is a valid operation? That seems like a lazy man's html stripper. Let's just blindly strip everything that can possibly be made into an html tag of any sort. Not. [2012-05-15 14:49:02] paj...@php.net > or < should be encoded then, see http://www.php.net/manual/en/filter.filters.sanitize.php btw, any option should be added using the option array or defaults, as it is the case already. [2012-05-15 14:45:27] iamcraigcampbell at gmail dot com So in that case I think strip_tags and filter_var are both broken. In this context: "It is true that 5<10" "It is true that 5 < 10" Neither of these are html tags so the string should not be touched regardless of if there is a space or not. [2012-05-15 14:42:47] reeze dot xia at gmail dot com PS: the reason why strip_tags() didn't strip it is '<' is followed by a space char but not without ending '>', this is the key point. look deep into the source code, there difference is switch whether or not to trait '<' followed by a(or more) spaces a tag or not. [2012-05-15 14:36:26] reeze dot xia at gmail dot com strip_tags will strip it even without the ending '>' if '<' followed by a non-space char. If we need to check whether is a closed tag it is a feature request to change it's behavior. it will break BC. 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 https://bugs.php.net/bug.php?id=62032 -- Edit this bug report at https://bugs.php.net/bug.php?id=62032&edit=1
Bug #62037 [Opn]: .user.ini ignores open_basedir parameter
Edit report at https://bugs.php.net/bug.php?id=62037&edit=1 ID: 62037 User updated by:karlis dot kisis at gmail dot com Reported by:karlis dot kisis at gmail dot com Summary:.user.ini ignores open_basedir parameter Status: Open Type: Bug Package:Safe Mode/open_basedir Operating System: CentOS 6.2 x86_64 PHP Version:5.3.13 Block user comment: N Private report: N New Comment: turns out that if the master value for open_basedir is None, then .user.ini value works! seems that .user.ini cannot override the master value from php.ini if open_basedir is defined. still a bug in my opinion. Previous Comments: [2012-05-15 14:33:52] karlis dot kisis at gmail dot com Description: open_basedir parameter is ignored in .user.ini: max_input_time = 333 open_basedir = "/home" display_errors = On include_path = "/home" the rest of the parameters from above work fine. php is run as fcgi on apache 2.2.22 with mod_fcgid.c. according to the docs, open_basedir should be configurable anywhere since version 5.3 Test script: --- changed parameters are shown in phpinfo(), except open_basedir which remains unchanged. Expected result: open_basedir setting from .user.ini to be in effect. -- Edit this bug report at https://bugs.php.net/bug.php?id=62037&edit=1
Bug #62032 [Com]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 Comment by: aleksey dot v dot korzun at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: How is stripping anything after < with a space is a valid operation? That seems like a lazy man's html stripper. Let's just blindly strip everything that can possibly be made into an html tag of any sort. Not. Previous Comments: [2012-05-15 14:49:02] paj...@php.net > or < should be encoded then, see http://www.php.net/manual/en/filter.filters.sanitize.php btw, any option should be added using the option array or defaults, as it is the case already. [2012-05-15 14:45:27] iamcraigcampbell at gmail dot com So in that case I think strip_tags and filter_var are both broken. In this context: "It is true that 5<10" "It is true that 5 < 10" Neither of these are html tags so the string should not be touched regardless of if there is a space or not. [2012-05-15 14:42:47] reeze dot xia at gmail dot com PS: the reason why strip_tags() didn't strip it is '<' is followed by a space char but not without ending '>', this is the key point. look deep into the source code, there difference is switch whether or not to trait '<' followed by a(or more) spaces a tag or not. [2012-05-15 14:36:26] reeze dot xia at gmail dot com strip_tags will strip it even without the ending '>' if '<' followed by a non-space char. If we need to check whether is a closed tag it is a feature request to change it's behavior. it will break BC. [2012-05-15 14:26:52] iamcraigcampbell at gmail dot com Well I can understand stripping it if there is a closing > somewhere, but if it is a < that is not followed by a matching > then it should be allowed in the string and not stripped. I think strip_tags works as expected. 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 https://bugs.php.net/bug.php?id=62032 -- Edit this bug report at https://bugs.php.net/bug.php?id=62032&edit=1
Bug #62032 [Opn]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 Updated by: paj...@php.net Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: > or < should be encoded then, see http://www.php.net/manual/en/filter.filters.sanitize.php btw, any option should be added using the option array or defaults, as it is the case already. Previous Comments: [2012-05-15 14:45:27] iamcraigcampbell at gmail dot com So in that case I think strip_tags and filter_var are both broken. In this context: "It is true that 5<10" "It is true that 5 < 10" Neither of these are html tags so the string should not be touched regardless of if there is a space or not. [2012-05-15 14:42:47] reeze dot xia at gmail dot com PS: the reason why strip_tags() didn't strip it is '<' is followed by a space char but not without ending '>', this is the key point. look deep into the source code, there difference is switch whether or not to trait '<' followed by a(or more) spaces a tag or not. [2012-05-15 14:36:26] reeze dot xia at gmail dot com strip_tags will strip it even without the ending '>' if '<' followed by a non-space char. If we need to check whether is a closed tag it is a feature request to change it's behavior. it will break BC. [2012-05-15 14:26:52] iamcraigcampbell at gmail dot com Well I can understand stripping it if there is a closing > somewhere, but if it is a < that is not followed by a matching > then it should be allowed in the string and not stripped. I think strip_tags works as expected. [2012-05-15 14:24:14] reeze dot xia at gmail dot com Hi, I think it's a document problem. you could refer this commit: http://svn.php.net/viewvc?view=revision&revision=225196 strip_tags() didn't allow space after < so strip_tags didn't trait it as a invalid tag so it didn't get striped. filter_var allow space after < so, it striped everything after <. I think we could add an extra paramater to strip_tags() allow space after < and document it eg: string strip_tags(string str [, string allowable_tags = null [, bool allow_tag_spaces = false]]) 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 https://bugs.php.net/bug.php?id=62032 -- Edit this bug report at https://bugs.php.net/bug.php?id=62032&edit=1
Bug #62032 [Opn]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 User updated by:iamcraigcampbell at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: So in that case I think strip_tags and filter_var are both broken. In this context: "It is true that 5<10" "It is true that 5 < 10" Neither of these are html tags so the string should not be touched regardless of if there is a space or not. Previous Comments: [2012-05-15 14:42:47] reeze dot xia at gmail dot com PS: the reason why strip_tags() didn't strip it is '<' is followed by a space char but not without ending '>', this is the key point. look deep into the source code, there difference is switch whether or not to trait '<' followed by a(or more) spaces a tag or not. [2012-05-15 14:36:26] reeze dot xia at gmail dot com strip_tags will strip it even without the ending '>' if '<' followed by a non-space char. If we need to check whether is a closed tag it is a feature request to change it's behavior. it will break BC. [2012-05-15 14:26:52] iamcraigcampbell at gmail dot com Well I can understand stripping it if there is a closing > somewhere, but if it is a < that is not followed by a matching > then it should be allowed in the string and not stripped. I think strip_tags works as expected. [2012-05-15 14:24:14] reeze dot xia at gmail dot com Hi, I think it's a document problem. you could refer this commit: http://svn.php.net/viewvc?view=revision&revision=225196 strip_tags() didn't allow space after < so strip_tags didn't trait it as a invalid tag so it didn't get striped. filter_var allow space after < so, it striped everything after <. I think we could add an extra paramater to strip_tags() allow space after < and document it eg: string strip_tags(string str [, string allowable_tags = null [, bool allow_tag_spaces = false]]) [2012-05-14 17:19:48] iamcraigcampbell at gmail dot com Description: Noticed that for strings with < in them outside of html tags, filter_var will strip out all characters that come after the <. Test script: --- https://bugs.php.net/bug.php?id=62032&edit=1
Bug #62032 [Com]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 Comment by: reeze dot xia at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: PS: the reason why strip_tags() didn't strip it is '<' is followed by a space char but not without ending '>', this is the key point. look deep into the source code, there difference is switch whether or not to trait '<' followed by a(or more) spaces a tag or not. Previous Comments: [2012-05-15 14:36:26] reeze dot xia at gmail dot com strip_tags will strip it even without the ending '>' if '<' followed by a non-space char. If we need to check whether is a closed tag it is a feature request to change it's behavior. it will break BC. [2012-05-15 14:26:52] iamcraigcampbell at gmail dot com Well I can understand stripping it if there is a closing > somewhere, but if it is a < that is not followed by a matching > then it should be allowed in the string and not stripped. I think strip_tags works as expected. [2012-05-15 14:24:14] reeze dot xia at gmail dot com Hi, I think it's a document problem. you could refer this commit: http://svn.php.net/viewvc?view=revision&revision=225196 strip_tags() didn't allow space after < so strip_tags didn't trait it as a invalid tag so it didn't get striped. filter_var allow space after < so, it striped everything after <. I think we could add an extra paramater to strip_tags() allow space after < and document it eg: string strip_tags(string str [, string allowable_tags = null [, bool allow_tag_spaces = false]]) [2012-05-14 17:19:48] iamcraigcampbell at gmail dot com Description: Noticed that for strings with < in them outside of html tags, filter_var will strip out all characters that come after the <. Test script: --- https://bugs.php.net/bug.php?id=62032&edit=1
Bug #62032 [Com]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 Comment by: reeze dot xia at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: strip_tags will strip it even without the ending '>' if '<' followed by a non-space char. If we need to check whether is a closed tag it is a feature request to change it's behavior. it will break BC. Previous Comments: [2012-05-15 14:26:52] iamcraigcampbell at gmail dot com Well I can understand stripping it if there is a closing > somewhere, but if it is a < that is not followed by a matching > then it should be allowed in the string and not stripped. I think strip_tags works as expected. [2012-05-15 14:24:14] reeze dot xia at gmail dot com Hi, I think it's a document problem. you could refer this commit: http://svn.php.net/viewvc?view=revision&revision=225196 strip_tags() didn't allow space after < so strip_tags didn't trait it as a invalid tag so it didn't get striped. filter_var allow space after < so, it striped everything after <. I think we could add an extra paramater to strip_tags() allow space after < and document it eg: string strip_tags(string str [, string allowable_tags = null [, bool allow_tag_spaces = false]]) [2012-05-14 17:19:48] iamcraigcampbell at gmail dot com Description: Noticed that for strings with < in them outside of html tags, filter_var will strip out all characters that come after the <. Test script: --- https://bugs.php.net/bug.php?id=62032&edit=1
[PHP-BUG] Bug #62037 [NEW]: .user.ini ignores open_basedir parameter
From: Operating system: CentOS 6.2 x86_64 PHP version: 5.3.13 Package: Safe Mode/open_basedir Bug Type: Bug Bug description:.user.ini ignores open_basedir parameter Description: open_basedir parameter is ignored in .user.ini: max_input_time = 333 open_basedir = "/home" display_errors = On include_path = "/home" the rest of the parameters from above work fine. php is run as fcgi on apache 2.2.22 with mod_fcgid.c. according to the docs, open_basedir should be configurable anywhere since version 5.3 Test script: --- changed parameters are shown in phpinfo(), except open_basedir which remains unchanged. Expected result: open_basedir setting from .user.ini to be in effect. -- Edit bug report at https://bugs.php.net/bug.php?id=62037&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62037&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62037&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62037&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62037&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62037&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62037&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62037&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62037&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62037&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62037&r=support Expected behavior: https://bugs.php.net/fix.php?id=62037&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62037&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62037&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62037&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62037&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62037&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62037&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62037&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62037&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62037&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62037&r=mysqlcfg
Bug #62032 [Opn]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 User updated by:iamcraigcampbell at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: Well I can understand stripping it if there is a closing > somewhere, but if it is a < that is not followed by a matching > then it should be allowed in the string and not stripped. I think strip_tags works as expected. Previous Comments: [2012-05-15 14:24:14] reeze dot xia at gmail dot com Hi, I think it's a document problem. you could refer this commit: http://svn.php.net/viewvc?view=revision&revision=225196 strip_tags() didn't allow space after < so strip_tags didn't trait it as a invalid tag so it didn't get striped. filter_var allow space after < so, it striped everything after <. I think we could add an extra paramater to strip_tags() allow space after < and document it eg: string strip_tags(string str [, string allowable_tags = null [, bool allow_tag_spaces = false]]) [2012-05-14 17:19:48] iamcraigcampbell at gmail dot com Description: Noticed that for strings with < in them outside of html tags, filter_var will strip out all characters that come after the <. Test script: --- https://bugs.php.net/bug.php?id=62032&edit=1
Bug #62032 [Com]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 Comment by: reeze dot xia at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: Hi, I think it's a document problem. you could refer this commit: http://svn.php.net/viewvc?view=revision&revision=225196 strip_tags() didn't allow space after < so strip_tags didn't trait it as a invalid tag so it didn't get striped. filter_var allow space after < so, it striped everything after <. I think we could add an extra paramater to strip_tags() allow space after < and document it eg: string strip_tags(string str [, string allowable_tags = null [, bool allow_tag_spaces = false]]) Previous Comments: [2012-05-14 17:19:48] iamcraigcampbell at gmail dot com Description: Noticed that for strings with < in them outside of html tags, filter_var will strip out all characters that come after the <. Test script: --- https://bugs.php.net/bug.php?id=62032&edit=1
Bug #60817 [Csd]: stream_get_line() incorrectly blocks
Edit report at https://bugs.php.net/bug.php?id=60817&edit=1 ID: 60817 Updated by: cataphr...@php.net Reported by:landeholm at gmail dot com Summary:stream_get_line() incorrectly blocks Status: Closed Type: Bug Package:Streams related Operating System: Linux/Ubuntu PHP Version:5.3.9 Assigned To:cataphract Block user comment: N Private report: N New Comment: This fix is only on 5.3.11, so it's normal you're experiencing the problem in 5.3.10. Previous Comments: [2012-05-15 12:23:04] olouvignes at gmail dot com Just migrated from 11.10 w/ php5.3.6-13 to 12.04 w/ php5.3.10-1 and this new php version broken a beanstalkd socket. It does not stop on "\r\n" anymore and hangs till timeout, while it works correctly on 5.3.6-13. [2012-04-18 09:46:27] larue...@php.net Automatic comment on behalf of cataphract Revision: http://git.php.net/?p=php-src.git;a=commit;h=f5a457318217a66fddc0d47af04a00f144dcbcec Log: - Further fix for bug #60455 (stream_get_line misbehaves if EOF is not detected together with the last read). - Fixed bug #60817 (stream_get_line() reads from stream even when there is already sufficient data buffered). stream_get_line() now behaves more like fgets(), as is documented. #withheld commit to 5.4 [2012-03-06 14:47:41] john dot papaioannou at gmail dot com I am still seeing this issue using the code given by landeholm at gmail dot com (broken down into two scripts because I 'm on Windows). Specifically, referring to this line: print "server got line: " . stream_get_line($socket2, 1024, "\r\n") . "\n"; * with a buffer size of 1024, the read times out * with buffer sizes smaller or equal to the lines actually being written from the client (e.g. tried 5 and 8 bytes) the read works Windows 7 x64, PHP 5.3.10 x86 on Apache 2.2.21 [2012-03-05 01:56:18] s...@php.net Re-opened to track 5.4. Please merge to 5.4 and close. [2012-01-22 20:57:19] cataphr...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Fixed, now the function doesn't try to fill the buffer with $length bytes; it behaves more like fgets() typically returning false in the last iteration (if the file ends with the delimiter). 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 https://bugs.php.net/bug.php?id=60817 -- Edit this bug report at https://bugs.php.net/bug.php?id=60817&edit=1
Bug #60817 [ReO->Csd]: stream_get_line() incorrectly blocks
Edit report at https://bugs.php.net/bug.php?id=60817&edit=1 ID: 60817 Updated by: cataphr...@php.net Reported by:landeholm at gmail dot com Summary:stream_get_line() incorrectly blocks -Status: Re-Opened +Status: Closed Type: Bug Package:Streams related Operating System: Linux/Ubuntu PHP Version:5.3.9 Assigned To:cataphract Block user comment: N Private report: N Previous Comments: [2012-05-15 12:23:04] olouvignes at gmail dot com Just migrated from 11.10 w/ php5.3.6-13 to 12.04 w/ php5.3.10-1 and this new php version broken a beanstalkd socket. It does not stop on "\r\n" anymore and hangs till timeout, while it works correctly on 5.3.6-13. [2012-04-18 09:46:27] larue...@php.net Automatic comment on behalf of cataphract Revision: http://git.php.net/?p=php-src.git;a=commit;h=f5a457318217a66fddc0d47af04a00f144dcbcec Log: - Further fix for bug #60455 (stream_get_line misbehaves if EOF is not detected together with the last read). - Fixed bug #60817 (stream_get_line() reads from stream even when there is already sufficient data buffered). stream_get_line() now behaves more like fgets(), as is documented. #withheld commit to 5.4 [2012-03-06 14:47:41] john dot papaioannou at gmail dot com I am still seeing this issue using the code given by landeholm at gmail dot com (broken down into two scripts because I 'm on Windows). Specifically, referring to this line: print "server got line: " . stream_get_line($socket2, 1024, "\r\n") . "\n"; * with a buffer size of 1024, the read times out * with buffer sizes smaller or equal to the lines actually being written from the client (e.g. tried 5 and 8 bytes) the read works Windows 7 x64, PHP 5.3.10 x86 on Apache 2.2.21 [2012-03-05 01:56:18] s...@php.net Re-opened to track 5.4. Please merge to 5.4 and close. [2012-01-22 20:57:19] cataphr...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Fixed, now the function doesn't try to fill the buffer with $length bytes; it behaves more like fgets() typically returning false in the last iteration (if the file ends with the delimiter). 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 https://bugs.php.net/bug.php?id=60817 -- Edit this bug report at https://bugs.php.net/bug.php?id=60817&edit=1
Bug #19451 [Opn->Nab]: Fucking Guestbook!, Please help me, It's very important for me
Edit report at https://bugs.php.net/bug.php?id=19451&edit=1
ID: 19451
Updated by: paj...@php.net
Reported by:ikez2605 at gmail dot com
Summary:Fucking Guestbook!, Please help me, It's very
important for me
-Status: Open
+Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Win 98 SE
PHP Version:4.2.3
Block user comment: Y
Private report: N
New Comment:
.
Previous Comments:
[2002-09-17 07:40:46] der...@php.net
Sorry, but the bug system is not the appropriate forum for asking
support questions. Your problem does not imply a bug in PHP itself.
For a list of more appropriate places to ask for help using PHP,
please visit http://www.php.net/support.php
Thank you for your interest in PHP.
[2002-09-17 07:37:10] kazworks at t-online dot de
.
[2002-09-17 07:36:43] der...@php.net
In PHP 4.2.0, the 'register_globals' setting default changed to
'off'. See http://www.php.net/release_4_2_0.php for more info.
We are sorry about the inconvenience, but this change was a necessary
part of our efforts to make PHP scripting more secure and portable.
[2002-09-17 07:35:31] ikez2605 at gmail dot com
Look here, this is the sourcetext of my guestbook, but if i tried to use, there
is the notice:
Undefined variable 'message'
!Sorry for my bad English!
-Umbrüche
$eintrag=nl2br($eintrag);
//Eingaben überprüfen
if(strlen($name)<3){
//Kein richtiger Name eingegeben
$error_msg="Bitte geben Sie Ihren Namen an";
}
if(strlen($eintrag)<3){
//Kein Eintrag vorgenommen
$error_msg.="Bitte geben Sie auch etwas in das Gästebuch ein.";
}
if(ereg("^[_a-zA-Z0-9-]+(\.[_a-zA-Z0-9-]+)*@([a-zA-Z0-9-]+\.)+([a-zA-Z]{2,4})$",$email)){
//Mailadresse korrekt angegeben - Name entsprechend formatieren
$name="mailto:"; . $email . ">" . $name . "";
}
if(ereg("^([a-zA-Z0-9-]+\.)+([a-zA-Z]{2,4})$",$homepage)){
//Es wurde auch eine Homepageadresse angegeben - entsprechende Formatierung
vornehmen
if(!ereg("^http:",$homepage)){
//http:// fehlt in der Angabe der Adresse - hier ergänzen
$homepage="http://"; . $homepage;
}
$hp_format="Homepage: " .
$homepage . "";
}
//Ende Eingaben überprüfen
if(isset($error_msg)){
//Fehlerhafte Angaben - Hinweis ausgeben und keinen Eintrag vornehmen
$message ="Ihr Eintrag konnte leider nicht in unser Gästebuch
aufgenommen werden:";
$message.=$error_msg;
$message.="Klicken Sie auf zurück.";
}else{
//Neuen Gästebucheintrag vornehmen
//Neuen Gästebucheintrag formatieren
$new_entry ="\n";
$new_entry.=" \n";
$new_entry.="Name: " . $name .
$hp_format . "\n";
$new_entry.="" . date("d.m.Y H:i") .
"\n";
$new_entry.=" \n";
$new_entry.=" \n";
$new_entry.="\n";
$new_entry.=" " . $eintrag . "\n";
$new_entry.="\n";
$new_entry.=" \n";
$new_entry.=" \n";
$new_entry.="\n";
$new_entry.=" \n";
$new_entry.="\n";
$new_entry.=" \n";
$new_entry.="\n";
$guestfile="guestbook_data.html";
//Zuerst alte Einträge auslesen
if(file_exists($guestfile)) {
$fp=fopen($guestfile,"r");
$guest_data=fread($fp,filesize($guestfile));
fclose($fp);
}
//Gästebucheinträge neu anlegen und den neuen an den Beginn schreiben
$fp=fopen($guestfile,"w");
flock($fp,1);
fputs($fp,$new_entry);
if(isset($guest_data)) fputs($fp,$guest_data);
flock($fp,3);
fclose($fp);
//Mail verschicken
$recipient="kazwo...@t-online.de";
$subject="Neuer Eintrag im Gaestebuch";
$header="From: webmas...@kazworks.net\n";
$mail_body="Neuer Eintrag im Gaestebuch";
mail($recipient,$subject,$mail_body,$header);
}
}
?>
P.S If you want to help me, you will need the files guestbook_data.html and
guestbook_new.php,
guestbook_data.html is a empty .html-file,
and here is the source text of guestbook_new.php:
Name :
E-Mail :
Homepage :
Kommentar :itschoritly
--
Edit this bug report at https://bugs.php.net/bug.php?id=19451&edit=1
Bug #60817 [Com]: stream_get_line() incorrectly blocks
Edit report at https://bugs.php.net/bug.php?id=60817&edit=1 ID: 60817 Comment by: olouvignes at gmail dot com Reported by:landeholm at gmail dot com Summary:stream_get_line() incorrectly blocks Status: Re-Opened Type: Bug Package:Streams related Operating System: Linux/Ubuntu PHP Version:5.3.9 Assigned To:cataphract Block user comment: N Private report: N New Comment: Just migrated from 11.10 w/ php5.3.6-13 to 12.04 w/ php5.3.10-1 and this new php version broken a beanstalkd socket. It does not stop on "\r\n" anymore and hangs till timeout, while it works correctly on 5.3.6-13. Previous Comments: [2012-04-18 09:46:27] larue...@php.net Automatic comment on behalf of cataphract Revision: http://git.php.net/?p=php-src.git;a=commit;h=f5a457318217a66fddc0d47af04a00f144dcbcec Log: - Further fix for bug #60455 (stream_get_line misbehaves if EOF is not detected together with the last read). - Fixed bug #60817 (stream_get_line() reads from stream even when there is already sufficient data buffered). stream_get_line() now behaves more like fgets(), as is documented. #withheld commit to 5.4 [2012-03-06 14:47:41] john dot papaioannou at gmail dot com I am still seeing this issue using the code given by landeholm at gmail dot com (broken down into two scripts because I 'm on Windows). Specifically, referring to this line: print "server got line: " . stream_get_line($socket2, 1024, "\r\n") . "\n"; * with a buffer size of 1024, the read times out * with buffer sizes smaller or equal to the lines actually being written from the client (e.g. tried 5 and 8 bytes) the read works Windows 7 x64, PHP 5.3.10 x86 on Apache 2.2.21 [2012-03-05 01:56:18] s...@php.net Re-opened to track 5.4. Please merge to 5.4 and close. [2012-01-22 20:57:19] cataphr...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Fixed, now the function doesn't try to fill the buffer with $length bytes; it behaves more like fgets() typically returning false in the last iteration (if the file ends with the delimiter). [2012-01-22 20:30:38] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=322582 Log: - Further fix for bug #60455 (stream_get_line misbehaves if EOF is not detected together with the last read). - Fixed bug #60817 (stream_get_line() reads from stream even when there is already sufficient data buffered). stream_get_line() now behaves more like fgets(), as is documented. #withheld commit to 5.4 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 https://bugs.php.net/bug.php?id=60817 -- Edit this bug report at https://bugs.php.net/bug.php?id=60817&edit=1
Bug #19451 [->Opn]: Fucking Guestbook!, Please help me, It's very important for me
Edit report at https://bugs.php.net/bug.php?id=19451&edit=1
ID: 19451
Updated by: paj...@php.net
Reported by:ikez2605 at gmail dot com
Summary:Fucking Guestbook!, Please help me, It's very
important for me
-Status:
+Status: Open
Type: Bug
Package:*General Issues
Operating System: Win 98 SE
PHP Version:4.2.3
-Block user comment: No
+Block user comment: Yes
Private report: N
Previous Comments:
[2002-09-17 07:40:46] der...@php.net
Sorry, but the bug system is not the appropriate forum for asking
support questions. Your problem does not imply a bug in PHP itself.
For a list of more appropriate places to ask for help using PHP,
please visit http://www.php.net/support.php
Thank you for your interest in PHP.
[2002-09-17 07:37:10] kazworks at t-online dot de
.
[2002-09-17 07:36:43] der...@php.net
In PHP 4.2.0, the 'register_globals' setting default changed to
'off'. See http://www.php.net/release_4_2_0.php for more info.
We are sorry about the inconvenience, but this change was a necessary
part of our efforts to make PHP scripting more secure and portable.
[2002-09-17 07:35:31] ikez2605 at gmail dot com
Look here, this is the sourcetext of my guestbook, but if i tried to use, there
is the notice:
Undefined variable 'message'
!Sorry for my bad English!
-Umbrüche
$eintrag=nl2br($eintrag);
//Eingaben überprüfen
if(strlen($name)<3){
//Kein richtiger Name eingegeben
$error_msg="Bitte geben Sie Ihren Namen an";
}
if(strlen($eintrag)<3){
//Kein Eintrag vorgenommen
$error_msg.="Bitte geben Sie auch etwas in das Gästebuch ein.";
}
if(ereg("^[_a-zA-Z0-9-]+(\.[_a-zA-Z0-9-]+)*@([a-zA-Z0-9-]+\.)+([a-zA-Z]{2,4})$",$email)){
//Mailadresse korrekt angegeben - Name entsprechend formatieren
$name="mailto:"; . $email . ">" . $name . "";
}
if(ereg("^([a-zA-Z0-9-]+\.)+([a-zA-Z]{2,4})$",$homepage)){
//Es wurde auch eine Homepageadresse angegeben - entsprechende Formatierung
vornehmen
if(!ereg("^http:",$homepage)){
//http:// fehlt in der Angabe der Adresse - hier ergänzen
$homepage="http://"; . $homepage;
}
$hp_format="Homepage: " .
$homepage . "";
}
//Ende Eingaben überprüfen
if(isset($error_msg)){
//Fehlerhafte Angaben - Hinweis ausgeben und keinen Eintrag vornehmen
$message ="Ihr Eintrag konnte leider nicht in unser Gästebuch
aufgenommen werden:";
$message.=$error_msg;
$message.="Klicken Sie auf zurück.";
}else{
//Neuen Gästebucheintrag vornehmen
//Neuen Gästebucheintrag formatieren
$new_entry ="\n";
$new_entry.=" \n";
$new_entry.="Name: " . $name .
$hp_format . "\n";
$new_entry.="" . date("d.m.Y H:i") .
"\n";
$new_entry.=" \n";
$new_entry.=" \n";
$new_entry.="\n";
$new_entry.=" " . $eintrag . "\n";
$new_entry.="\n";
$new_entry.=" \n";
$new_entry.=" \n";
$new_entry.="\n";
$new_entry.=" \n";
$new_entry.="\n";
$new_entry.=" \n";
$new_entry.="\n";
$guestfile="guestbook_data.html";
//Zuerst alte Einträge auslesen
if(file_exists($guestfile)) {
$fp=fopen($guestfile,"r");
$guest_data=fread($fp,filesize($guestfile));
fclose($fp);
}
//Gästebucheinträge neu anlegen und den neuen an den Beginn schreiben
$fp=fopen($guestfile,"w");
flock($fp,1);
fputs($fp,$new_entry);
if(isset($guest_data)) fputs($fp,$guest_data);
flock($fp,3);
fclose($fp);
//Mail verschicken
$recipient="kazwo...@t-online.de";
$subject="Neuer Eintrag im Gaestebuch";
$header="From: webmas...@kazworks.net\n";
$mail_body="Neuer Eintrag im Gaestebuch";
mail($recipient,$subject,$mail_body,$header);
}
}
?>
P.S If you want to help me, you will need the files guestbook_data.html and
guestbook_new.php,
guestbook_data.html is a empty .html-file,
and here is the source text of guestbook_new.php:
Name :
E-Mail :
Homepage :
Kommentar :itschoritly
--
Edit this bug report at https://bugs.php.net/bug.php?id=19451&edit=1
Bug #19451 [Nab]: Fucking Guestbook!, Please help me, It's very important for me
Edit report at https://bugs.php.net/bug.php?id=19451&edit=1
ID: 19451
User updated by:ikez2605 at gmail dot com
Reported by:ikez2605 at gmail dot com
Summary:Fucking Guestbook!, Please help me, It's very
important for me
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Win 98 SE
PHP Version:4.2.3
Block user comment: N
Private report: N
New Comment:
http://www.coach-bags-wholesale.net>coach outlet coach outlet
NIykdWndzkpDIH http://www.coach-bags-wholesale.net>coach purses
coach handbags TMfcrNwqhbhFCQ http://www.coach-bags-wholesale.net>coach
outlet store online coach shoes
Previous Comments:
[2002-09-17 07:40:46] der...@php.net
Sorry, but the bug system is not the appropriate forum for asking
support questions. Your problem does not imply a bug in PHP itself.
For a list of more appropriate places to ask for help using PHP,
please visit http://www.php.net/support.php
Thank you for your interest in PHP.
[2002-09-17 07:37:10] kazworks at t-online dot de
.
[2002-09-17 07:36:43] der...@php.net
In PHP 4.2.0, the 'register_globals' setting default changed to
'off'. See http://www.php.net/release_4_2_0.php for more info.
We are sorry about the inconvenience, but this change was a necessary
part of our efforts to make PHP scripting more secure and portable.
[2002-09-17 07:35:31] ikez2605 at gmail dot com
Look here, this is the sourcetext of my guestbook, but if i tried to use, there
is the notice:
Undefined variable 'message'
!Sorry for my bad English!
-Umbrüche
$eintrag=nl2br($eintrag);
//Eingaben überprüfen
if(strlen($name)<3){
//Kein richtiger Name eingegeben
$error_msg="Bitte geben Sie Ihren Namen an";
}
if(strlen($eintrag)<3){
//Kein Eintrag vorgenommen
$error_msg.="Bitte geben Sie auch etwas in das Gästebuch ein.";
}
if(ereg("^[_a-zA-Z0-9-]+(\.[_a-zA-Z0-9-]+)*@([a-zA-Z0-9-]+\.)+([a-zA-Z]{2,4})$",$email)){
//Mailadresse korrekt angegeben - Name entsprechend formatieren
$name="mailto:"; . $email . ">" . $name . "";
}
if(ereg("^([a-zA-Z0-9-]+\.)+([a-zA-Z]{2,4})$",$homepage)){
//Es wurde auch eine Homepageadresse angegeben - entsprechende Formatierung
vornehmen
if(!ereg("^http:",$homepage)){
//http:// fehlt in der Angabe der Adresse - hier ergänzen
$homepage="http://"; . $homepage;
}
$hp_format="Homepage: " .
$homepage . "";
}
//Ende Eingaben überprüfen
if(isset($error_msg)){
//Fehlerhafte Angaben - Hinweis ausgeben und keinen Eintrag vornehmen
$message ="Ihr Eintrag konnte leider nicht in unser Gästebuch
aufgenommen werden:";
$message.=$error_msg;
$message.="Klicken Sie auf zurück.";
}else{
//Neuen Gästebucheintrag vornehmen
//Neuen Gästebucheintrag formatieren
$new_entry ="\n";
$new_entry.=" \n";
$new_entry.="Name: " . $name .
$hp_format . "\n";
$new_entry.="" . date("d.m.Y H:i") .
"\n";
$new_entry.=" \n";
$new_entry.=" \n";
$new_entry.="\n";
$new_entry.=" " . $eintrag . "\n";
$new_entry.="\n";
$new_entry.=" \n";
$new_entry.=" \n";
$new_entry.="\n";
$new_entry.=" \n";
$new_entry.="\n";
$new_entry.=" \n";
$new_entry.="\n";
$guestfile="guestbook_data.html";
//Zuerst alte Einträge auslesen
if(file_exists($guestfile)) {
$fp=fopen($guestfile,"r");
$guest_data=fread($fp,filesize($guestfile));
fclose($fp);
}
//Gästebucheinträge neu anlegen und den neuen an den Beginn schreiben
$fp=fopen($guestfile,"w");
flock($fp,1);
fputs($fp,$new_entry);
if(isset($guest_data)) fputs($fp,$guest_data);
flock($fp,3);
fclose($fp);
//Mail verschicken
$recipient="kazwo...@t-online.de";
$subject="Neuer Eintrag im Gaestebuch";
$header="From: webmas...@kazworks.net\n";
$mail_body="Neuer Eintrag im Gaestebuch";
mail($recipient,$subject,$mail_body,$header);
}
}
?>
P.S If you want to help me, you will need the files guestbook_data.html and
guestbook_new.php,
guestbook_data.html is a empty .html-file,
and here is the source text of guestbook_new.php:
Name :
E-Mail :
Homepage :
Kommentar :itschoritly
--
Edit this bug report at https://bugs.php.net/bug.php?id=19451&edit=1
Bug #53185 [Com]: PDO_MYSQL constructor, PHP warning w/ Exception error mode
Edit report at https://bugs.php.net/bug.php?id=53185&edit=1
ID: 53185
Comment by: jach at wayf dot dk
Reported by:alexc223 at googlemail dot com
Summary:PDO_MYSQL constructor, PHP warning w/ Exception
error mode
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3.3
Assigned To:kalle
Block user comment: N
Private report: N
New Comment:
Same error on OSX version 3.5.10
Previous Comments:
[2010-12-22 17:19:46] alexc223 at googlemail dot com
Maybe there needs to be a way for it to know? Either way, it's highly annoying
since there is very little ways to handle it.
[2010-11-02 22:12:57] fel...@php.net
The warning come from mysqlnd_connect() call that nothing knows about such PDO
feature...
[2010-10-27 17:17:23] alexc223 at googlemail dot com
Description:
A PHP warning is generated even though I've explicitly set the PDO error mode
to
use exceptions. This warning occurs when the MySQL socket does not exist (for
example, if MySQL is not yet started).
This makes it quite impossible to handle.
Test script:
---
PDO::ERRMODE_EXCEPTION) );
} catch ( PDOException $e ) {
echo 'unable to connect';
}
?>
Expected result:
unable to connect
Actual result:
--
Warning: PDO::__construct(): [2002] No such file or directory (trying to
connect
via unix:///var/run/mysqld/mysqld.sock) in php shell code on line 2
unable to connect
--
Edit this bug report at https://bugs.php.net/bug.php?id=53185&edit=1
[PHP-BUG] Bug #62036 [NEW]: CURLOPT_RETURNTRANSFER] returns both boolean and response
From:
Operating system: N/A
PHP version: 5.3.13
Package: cURL related
Bug Type: Bug
Bug description:CURLOPT_RETURNTRANSFER] returns both boolean and response
Description:
When calling a API and converting the response to an associative array, the
returned response can not be converted because of the extra boolean in the
response. Only viewable when exit($response)
The options of the cURL operation are set using the @curl_setopt_array($ch,
$array).
When checked for the header, it does not indicate any problem and it
outputs the correct content (with content length)
When dumped the boolean is dumped with the correct response.
Test script:
---
// check if curl is available
if(!function_exists('curl_init')) throw new Exception('This method requires
cURL (http://php.net/curl), it seems like the extension isn\'t
installed.');
$url =
'http://ws.audioscrobbler.com/2.0/?method=album.getbuylinks&artist=radiohead&album=in%20rainbows&country=united%20kingdom&api_key=b25b959554ed76058ac220b7b2e0a026&format=json';
// set options
// $options[CURLOPT_URL] = (string) $url;
// $options[CURLOPT_USERAGENT] = 'PlonkHTTP '. self::version;
// $options[CURLOPT_FOLLOWLOCATION] = true;
// $options[CURLOPT_RETURNTRANSFER] = true;
// $options[CURLOPT_TIMEOUT] = 20;
// $options[CURLOPT_HEADER] = true;
// init
$curl = @curl_init();
// @curl_setopt_array($curl, $options);
curl_setopt($curl,CURLOPT_URL, (string) $url);
curl_setopt($curl,CURLOPT_USERAGENT,'PlonkHTTP');
curl_setopt($curl,CURLOPT_RETURNTRANSFER, true);
// execute
$response = @curl_exec($curl);
// fetch errors
$errorNumber = @curl_errno($curl);
$errorMessage = @curl_error($curl);
// close
@curl_close($curl);
Expected result:
The script will result in a decent response on a local webserver. In a
production environment, it gives the extra boolean when outputted.
Actual result:
--
http://ws.audioscrobbler.com/2.0/?method=album.getbuylinks&artist=radiohead&album=in%20rainbows&country=united%20kingdom&api_key=b25b959554ed76058ac220b7b2e0a026&format=json
--
Edit bug report at https://bugs.php.net/bug.php?id=62036&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62036&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62036&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62036&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62036&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62036&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62036&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62036&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62036&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62036&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62036&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62036&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62036&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62036&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62036&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62036&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62036&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62036&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62036&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62036&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62036&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62036&r=mysqlcfg
Bug #62022 [Asn]: Minor fixes to tests
Edit report at https://bugs.php.net/bug.php?id=62022&edit=1 ID: 62022 User updated by:z...@php.net Reported by:z...@php.net Summary:Minor fixes to tests Status: Assigned Type: Bug Package:Testing related Operating System: Any PHP Version:5.4Git-2012-05-14 (Git) Assigned To:z...@php.net Block user comment: N Private report: N New Comment: Tests updated except: ext/mysqli/tests/mysqli_options_openbasedir.phpt ext/standard/tests/strings/htmlentities15.phpt Previous Comments: [2012-05-14 12:32:38] z...@php.net Description: A few tests with very minor errors, caught by new run tests code. ext/dom/tests/DOMAttr_value_basic_001.phpt - change CREDIT to CREDITS ext/dom/tests/DOMAttr_value_basic_002.phpt ditto ext/dom/tests/DOMCharacterData_data_error_002.phpt ditto ext/dom/tests/DOMCharacterData_length_error_001.phpt ditto ext/mysqli/tests/mysqli_options_openbasedir.phpt remove empty INI section ext/posix/tests/posix_setgid_error.phpt remove empty CREDITS ext/reflection/tests/bug47254.phpt remove empty CLEAN section ext/standard/tests/file/windows_links/bug48746.phpt chenge CREDiT to CREDITS ext/standard/tests/file/windows_links/bug48746_1.phpt ditto ext/standard/tests/file/windows_links/bug48746_2.phpt ditto ext/standard/tests/file/windows_links/bug48746_3.phpt ditto ext/standard/tests/strings/htmlentities15.phpt COMMENT? check run-tests.php. -- Edit this bug report at https://bugs.php.net/bug.php?id=62022&edit=1
Bug #21260 [Opn->NoF]: phpBB fails to work with GD turned on
Edit report at https://bugs.php.net/bug.php?id=21260&edit=1 ID: 21260 Updated by: paj...@php.net Reported by:cmsaspopup at mail dot ru Summary:phpBB fails to work with GD turned on -Status: Open +Status: No Feedback Type: Bug Package:*General Issues Operating System: Linux PHP Version:4.3.0 Block user comment: N Private report: N Previous Comments: [2003-01-13 18:18:54] sni...@php.net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-12-28 22:35:24] poll...@php.net Please run the following test on your system: 1) Create a file named "testgd.php" in the document root of your webserver with the following content: 2) Browse the URL for that page (i.e.: http://myserver.com/testgd.php ) 3) Tell us if a white square with a black frame appears. If the image shows properly then the problem is likely with PHPBB and there's nothing anyone here can do. If not, then there may be a problem with your GD build. [2002-12-28 21:56:17] cmsaspopup at mail dot ru I use PHPbb on my web site(I have also already reported this problem to them) when I install PHP without the new GD support in 4.3.0 turned on everything works fine, however if I turn the GD support on the PHPbb fails to load and all I get is a blank page...no errors no anything The following are my configure lines PHPbb works ./configure --with-mysql=/mysql --with-apxs PHPbb doesn't work... ./configure --with-mysql=/mysql --with-apxs --with-gd --with-zlib-dir=/usr/include I should mention that I also use phpMyAdmin...and that works fine either way -- Edit this bug report at https://bugs.php.net/bug.php?id=21260&edit=1
Bug #21260 [->Opn]: phpBB fails to work with GD turned on
Edit report at https://bugs.php.net/bug.php?id=21260&edit=1 ID: 21260 Updated by: paj...@php.net Reported by:cmsaspopup at mail dot ru Summary:phpBB fails to work with GD turned on -Status: +Status: Open Type: Bug Package:*General Issues Operating System: Linux PHP Version:4.3.0 Block user comment: N Private report: N Previous Comments: [2012-05-15 10:05:25] cmsaspopup at mail dot ru ÐÑем пÑивеÑ! ÐÑли Ð²Ñ Ñ Ð¾ÑиÑе ÑобÑÑвеннÑй ÑекламнÑй Ð±Ð¸Ð·Ð½ÐµÑ Ð² ÑеÑи ÐнÑеÑнеÑ, Ñогда вам бÑÐ´ÐµÑ Ð¸Ð½ÑеÑеÑна ÑÑа ÑÑаÑÑÑ! РнаÑале 2007 года наÑалаÑÑ ÑазÑабоÑка ÑкÑипÑа Ñекламного ÑеÑвиÑа PopUp v1.0, компанией Minatrix. Ð Ñо вÑÐµÐ¼Ñ ÑÑо бÑл ÑамÑй пик подобной ÑекламÑ. Сам ÑкÑÐ¸Ð¿Ñ Ð±Ñл оÑÐµÐ½Ñ Ð¿ÑоÑÑой и имел минималÑнÑй Ð½Ð°Ð±Ð¾Ñ ÑÑнкÑий, но не ÑмоÑÑÑ Ð½Ð° ÑÑо, ÑÑал лидиÑÑÑÑим пÑодÑкÑом в Ñекламном бизнеÑе. С Ñого вÑемени, велиÑÑ Ð¿Ð¾ÑÑоÑннÑе доÑабоÑки и внедÑÐµÐ½Ð¸Ñ Ð½Ð¾Ð²ÑÑ Ð²Ð¸Ð´Ð¾Ð² ÑекламÑ, пÑоÑÑл множеÑÑво ÑÑадий ÑеÑÑиÑованиÑ. ÐÑли ÑÑÑÐ¸Ð½Ñ Ð²Ñе Ð¿Ð¾Ð¶ÐµÐ»Ð°Ð½Ð¸Ñ ÐºÐ»Ð¸ÐµÐ½Ñов и в иÑоге полÑÑилÑÑ Ð¼Ð¾ÑнейÑий ÑкÑÐ¸Ð¿Ñ Ð² данном напÑавлении. Ðа даннÑй Ð¼Ð¾Ð¼ÐµÐ½Ñ Ñ Ð³Ð¾ÑдоÑÑÑÑ Ð¼Ð¾Ð¶ÐµÐ¼ ÑообÑиÑÑ, ÑÑо на даннÑй Ð¼Ð¾Ð¼ÐµÐ½Ñ - ÑÑо ÑамÑй ÑÑнкÑионалÑнÑй, не имеÑÑий ÑÑзвимоÑÑей, Ñ Ð¾ÑоÑо заÑиÑÑн Ð¾Ñ Ð²Ð·Ð»Ð¾Ð¼Ð¾Ð² и накÑÑÑок, поÑÑоÑнно-обновлÑемÑй пÑодÑкÑ. СÑоимоÑÑÑ ÑкÑипÑа в ÑооÑноÑении: каÑеÑÑво/Ñена поÑажаÑÑ Ð¼Ð½Ð¾Ð³Ð¸Ñ , Ñем более, ÑÑо Ð¼Ñ Ð²Ñегда идÑм на вÑÑÑеÑÑ ÐºÐ»Ð¸ÐµÐ½Ñа и пÑедлогаем гибкие ÑÑÐ»Ð¾Ð²Ð¸Ñ Ð¿Ð¾ÐºÑпки в ÑаÑÑÑоÑкÑ. ÐложеннÑе ÑÑедÑÑва в ÑкÑÐ¸Ð¿Ñ Ð±ÑÑÑÑо и легко окÑпаÑÑÑÑ! ÐÑÑ Ð·Ð°Ð²Ð¸ÑÐ¸Ñ ÑолÑко Ð¾Ñ Ð²Ð°ÑÐ¸Ñ Ð²Ð¾Ð·Ð¼Ð¾Ð¶Ð½Ð¾ÑÑей, Ð¶ÐµÐ»Ð°Ð½Ð¸Ñ Ð¸ ÑÑÑаÑегии ÑазвиÑиÑ! РпÑодаже поÑвилаÑÑ Ð½Ð¾Ð²Ð°Ñ Ð²ÐµÑÑÐ¸Ñ ÑкÑипÑа Ñекламного ÑеÑвиÑа: CMS AdminStation + PopUp v4.0 pro. СейÑÐ°Ñ Ñже Ñложно назваÑÑ ÑÑÐ¾Ñ ÑкÑÐ¸Ð¿Ñ PopUp, Ñ.к. в нÑм Ñже 9 попÑлÑÑнÑÑ Ð² ÑеÑи видов ÑекламÑ, а именно: 1. PopUp - Ñеклама 2. ÐаннеÑÐ½Ð°Ñ Ñеклама 3. ÐонÑекÑÑÐ½Ð°Ñ Ñеклама 4. ТизеÑÐ½Ð°Ñ Ñеклама 5. BodyClick (ClickUnder) 6. Peel-down (Ñголок) 7. ÐлаваÑÑий блок ÑÑÑлок 8. РаÑÑÑÑжка (Top-line) 9. ICQ-window 10. SLIDER Ðолее подÑобно Ð²Ñ Ð¼Ð¾Ð¶ÐµÑе ÑзнаÑÑ Ð½Ð° ÑайÑе: http://adminstation.ru/?ref=613 [2003-01-13 18:18:54] sni...@php.net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-12-28 22:35:24] poll...@php.net Please run the following test on your system: 1) Create a file named "testgd.php" in the document root of your webserver with the following content: 2) Browse the URL for that page (i.e.: http://myserver.com/testgd.php ) 3) Tell us if a white square with a black frame appears. If the image shows properly then the problem is likely with PHPBB and there's nothing anyone here can do. If not, then there may be a problem with your GD build. [2002-12-28 21:56:17] cmsaspopup at mail dot ru I use PHPbb on my web site(I have also already reported this problem to them) when I install PHP without the new GD support in 4.3.0 turned on everything works fine, however if I turn the GD support on the PHPbb fails to load and all I get is a blank page...no errors no anything The following are my configure lines PHPbb works ./configure --with-mysql=/mysql --with-apxs PHPbb doesn't work... ./configure --with-mysql=/mysql --with-apxs --with-gd --with-zlib-dir=/usr/include I should mention that I also use phpMyAdmin..
Bug #21260 [NoF]: phpBB fails to work with GD turned on
Edit report at https://bugs.php.net/bug.php?id=21260&edit=1 ID: 21260 User updated by:cmsaspopup at mail dot ru Reported by:cmsaspopup at mail dot ru Summary:phpBB fails to work with GD turned on Status: No Feedback Type: Bug -Package:GD related +Package:*General Issues Operating System: Linux PHP Version:4.3.0 Block user comment: N Private report: N New Comment: ÐÑем пÑивеÑ! ÐÑли Ð²Ñ Ñ Ð¾ÑиÑе ÑобÑÑвеннÑй ÑекламнÑй Ð±Ð¸Ð·Ð½ÐµÑ Ð² ÑеÑи ÐнÑеÑнеÑ, Ñогда вам бÑÐ´ÐµÑ Ð¸Ð½ÑеÑеÑна ÑÑа ÑÑаÑÑÑ! РнаÑале 2007 года наÑалаÑÑ ÑазÑабоÑка ÑкÑипÑа Ñекламного ÑеÑвиÑа PopUp v1.0, компанией Minatrix. Ð Ñо вÑÐµÐ¼Ñ ÑÑо бÑл ÑамÑй пик подобной ÑекламÑ. Сам ÑкÑÐ¸Ð¿Ñ Ð±Ñл оÑÐµÐ½Ñ Ð¿ÑоÑÑой и имел минималÑнÑй Ð½Ð°Ð±Ð¾Ñ ÑÑнкÑий, но не ÑмоÑÑÑ Ð½Ð° ÑÑо, ÑÑал лидиÑÑÑÑим пÑодÑкÑом в Ñекламном бизнеÑе. С Ñого вÑемени, велиÑÑ Ð¿Ð¾ÑÑоÑннÑе доÑабоÑки и внедÑÐµÐ½Ð¸Ñ Ð½Ð¾Ð²ÑÑ Ð²Ð¸Ð´Ð¾Ð² ÑекламÑ, пÑоÑÑл множеÑÑво ÑÑадий ÑеÑÑиÑованиÑ. ÐÑли ÑÑÑÐ¸Ð½Ñ Ð²Ñе Ð¿Ð¾Ð¶ÐµÐ»Ð°Ð½Ð¸Ñ ÐºÐ»Ð¸ÐµÐ½Ñов и в иÑоге полÑÑилÑÑ Ð¼Ð¾ÑнейÑий ÑкÑÐ¸Ð¿Ñ Ð² данном напÑавлении. Ðа даннÑй Ð¼Ð¾Ð¼ÐµÐ½Ñ Ñ Ð³Ð¾ÑдоÑÑÑÑ Ð¼Ð¾Ð¶ÐµÐ¼ ÑообÑиÑÑ, ÑÑо на даннÑй Ð¼Ð¾Ð¼ÐµÐ½Ñ - ÑÑо ÑамÑй ÑÑнкÑионалÑнÑй, не имеÑÑий ÑÑзвимоÑÑей, Ñ Ð¾ÑоÑо заÑиÑÑн Ð¾Ñ Ð²Ð·Ð»Ð¾Ð¼Ð¾Ð² и накÑÑÑок, поÑÑоÑнно-обновлÑемÑй пÑодÑкÑ. СÑоимоÑÑÑ ÑкÑипÑа в ÑооÑноÑении: каÑеÑÑво/Ñена поÑажаÑÑ Ð¼Ð½Ð¾Ð³Ð¸Ñ , Ñем более, ÑÑо Ð¼Ñ Ð²Ñегда идÑм на вÑÑÑеÑÑ ÐºÐ»Ð¸ÐµÐ½Ñа и пÑедлогаем гибкие ÑÑÐ»Ð¾Ð²Ð¸Ñ Ð¿Ð¾ÐºÑпки в ÑаÑÑÑоÑкÑ. ÐложеннÑе ÑÑедÑÑва в ÑкÑÐ¸Ð¿Ñ Ð±ÑÑÑÑо и легко окÑпаÑÑÑÑ! ÐÑÑ Ð·Ð°Ð²Ð¸ÑÐ¸Ñ ÑолÑко Ð¾Ñ Ð²Ð°ÑÐ¸Ñ Ð²Ð¾Ð·Ð¼Ð¾Ð¶Ð½Ð¾ÑÑей, Ð¶ÐµÐ»Ð°Ð½Ð¸Ñ Ð¸ ÑÑÑаÑегии ÑазвиÑиÑ! РпÑодаже поÑвилаÑÑ Ð½Ð¾Ð²Ð°Ñ Ð²ÐµÑÑÐ¸Ñ ÑкÑипÑа Ñекламного ÑеÑвиÑа: CMS AdminStation + PopUp v4.0 pro. СейÑÐ°Ñ Ñже Ñложно назваÑÑ ÑÑÐ¾Ñ ÑкÑÐ¸Ð¿Ñ PopUp, Ñ.к. в нÑм Ñже 9 попÑлÑÑнÑÑ Ð² ÑеÑи видов ÑекламÑ, а именно: 1. PopUp - Ñеклама 2. ÐаннеÑÐ½Ð°Ñ Ñеклама 3. ÐонÑекÑÑÐ½Ð°Ñ Ñеклама 4. ТизеÑÐ½Ð°Ñ Ñеклама 5. BodyClick (ClickUnder) 6. Peel-down (Ñголок) 7. ÐлаваÑÑий блок ÑÑÑлок 8. РаÑÑÑÑжка (Top-line) 9. ICQ-window 10. SLIDER Ðолее подÑобно Ð²Ñ Ð¼Ð¾Ð¶ÐµÑе ÑзнаÑÑ Ð½Ð° ÑайÑе: http://adminstation.ru/?ref=613 Previous Comments: [2003-01-13 18:18:54] sni...@php.net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-12-28 22:35:24] poll...@php.net Please run the following test on your system: 1) Create a file named "testgd.php" in the document root of your webserver with the following content: 2) Browse the URL for that page (i.e.: http://myserver.com/testgd.php ) 3) Tell us if a white square with a black frame appears. If the image shows properly then the problem is likely with PHPBB and there's nothing anyone here can do. If not, then there may be a problem with your GD build. [2002-12-28 21:56:17] cmsaspopup at mail dot ru I use PHPbb on my web site(I have also already reported this problem to them) when I install PHP without the new GD support in 4.3.0 turned on everything works fine, however if I turn the GD support on the PHPbb fails to load and all I get is a blank page...no errors no anything The following are my configure lines PHPbb works ./configure --with-mysql=/mysql --with-apxs PHPbb doesn't work... ./configure --with-mysql=/mysql --with-apxs --with-gd --with-zlib-dir=/usr/include I should mention that I also use phpMyAdmin...and that works fine either way ---
Bug #62035 [Opn]: Problem with ProFTPd hard quotas
Edit report at https://bugs.php.net/bug.php?id=62035&edit=1 ID: 62035 User updated by:incidencias at ultreia dot es Reported by:incidencias at ultreia dot es Summary:Problem with ProFTPd hard quotas Status: Open Type: Bug Package:FTP related PHP Version:5.4.3 Block user comment: N Private report: N New Comment: Ah, and here is my compilation information: PHP Version => 5.4.3--pl0-gentoo System => Linux jperez 3.2.0-sabayon #1 SMP Sat Feb 11 08:52:29 UTC 2012 x86_64 Build Date => May 15 2012 10:51:31 Configure Command => './configure' '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--prefix=/usr/lib64/php5.4' '--mandir=/usr/lib64/php5.4/man' '--infodir=/usr/lib64/php5.4/info' '--libdir=/usr/lib64/php5.4/lib' '--with-libdir=lib64' '--without-pear' '--disable-maintainer-zts' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-ctype' '--with-curl' '--without-curlwrappers' '--enable-dom' '--without-enchant' '--enable-exif' '--enable-fileinfo' '--enable-filter' '--enable-ftp' '--with-gettext' '--with-gmp' '--enable-hash' '--with-mhash' '--with-iconv' '--enable-intl' '--enable-ipv6' '--enable-json' '--with-kerberos=/usr' '--enable-libxml' '--enable-mbstring' '--with-mcrypt' '--without-mssql' '--with-onig=/usr' '--with-openssl' '--with-openssl-dir=/usr' '--enable-pcntl' '--enable-phar' '--enable-pdo' '--without-pgsql' '--enable-posix' '--with-pspell' '--without-recode' '--enable-simplexml' '--disable-shmop' '--with-snmp' '--enable-soap' '--enable-sockets' '--with-sqlite3=/usr' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--with-tidy' '--enable-tokenizer' '--enable-wddx' '--enable-xml' '--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--with-xsl' '--enable-zip' '--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb' '--with-db4' '--disable-flatfile' '--with-gdbm' '--disable-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--enable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-gd' '--with-imap' '--with-imap-ssl' '--with-mysql=mysqlnd' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=mysqlnd' '--without-pdo-dblib' '--with-pdo-mysql=mysqlnd' '--without-pdo-pgsql' '--with-pdo-sqlite=/usr' '--without-pdo-odbc' '--with-readline' '--without-libedit' '--without-mm' '--with-pcre-regex=/usr' '--with-pcre-dir=/usr' '--with-config-file-path=/etc/php/cli-php5.4' '--with-config-file-scan-dir=/etc/php/cli-php5.4/ext-active' '--disable-embed' '--enable-cli' '--disable-cgi' '--disable-fpm' '--without-apxs2' Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => /etc/php/cli-php5.4 Loaded Configuration File => /etc/php/cli-php5.4/php.ini Scan this dir for additional .ini files => /etc/php/cli-php5.4/ext-active Additional .ini files parsed => (none) PHP API => 20100412 PHP Extension => 20100525 Zend Extension => 220100525 Zend Extension Build => API220100525,NTS PHP Extension Build => API20100525,NTS Debug Build => no Thread Safety => disabled Zend Signal Handling => disabled Zend Memory Manager => enabled Zend Multibyte Support => provided by mbstring IPv6 Support => enabled DTrace Support => disabled I've also tried with latest snapshot with the same result: PHP Version => 5.5.0-dev System => Linux jperez 3.2.0-sabayon #1 SMP Sat Feb 11 08:52:29 UTC 2012 x86_64 Build Date => May 15 2012 11:18:19 Configure Command => './configure' '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--prefix=/usr/lib64/php5.4' '--mandir=/usr/lib64/php5.4/man' '--infodir=/usr/lib64/php5.4/info' '--libdir=/usr/lib64/php5.4/lib' '--with-libdir=lib64' '--without-pear' '--disable-maintainer-zts' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-ctype' '--with-curl' '--without-curlwrappers' '--enable-dom' '--without-enchant' '--enable-exif' '--enable-fileinfo' '--enable-filter' '--enable-ftp' '--with-gettext' '--with-gmp' '--enable-hash' '--with-mhash' '--with-iconv' '--enable-intl' '--enable-ipv6' '--enable-json' '--with-kerberos=/usr' '--enable-libxml' '--enable-mbstring' '--with-mcrypt' '--without-mssql' '--with-onig=/usr' '--with-openssl' '--with-openssl-dir=/usr' '--enable-pcntl' '--enable-phar' '--enable-pdo' '--without-pgsql' '--enable-posix' '--with-pspell' '--without-recode' '--enable-simplexml' '--disable-shmop' '--with-snmp' '--enable-soap' '--enable-sockets' '--with-sqlite3=/usr' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--with-tidy' '--en
Bug #62035 [Opn]: Problem with ProFTPd hard quotas
Edit report at https://bugs.php.net/bug.php?id=62035&edit=1
ID: 62035
User updated by:incidencias at ultreia dot es
Reported by:incidencias at ultreia dot es
Summary:Problem with ProFTPd hard quotas
Status: Open
Type: Bug
Package:FTP related
PHP Version:5.4.3
Block user comment: N
Private report: N
New Comment:
Well, you may realize that I swapped expected result and actual result.
It should be:
Expected result:
PHP Warning: ftp_put(): Transfer aborted. Disk quota exceeded.
Actual result:
--
PHP Warning: ftp_put(): Opening BINARY mode data connection
Previous Comments:
[2012-05-15 09:37:36] incidencias at ultreia dot es
Description:
If you try to upload a file to an FTP account in a ProFTPD server with hard
quotas and available space is less than file size, transfer will be accepted
receiving a "150 Opening BINARY mode data connection for " response. But
as soon as used space reaches quota, ProFTPD will interrupt transfer sending a
"552-Transfer aborted. Disk quota exceeded." message followed by "552 STOR:
notice: quota reached: '' removed".
PHP will know that transfer has failed but will return the first message
("Opening BINARY mode data connection") as error message instead of one of the
552 real error messages.
If there is no free disk space in FTP account (which can happen if, for
example, you are using ProFTPD soft quotas), ProFTPD will no initially accept
the transfer sending the 150 response, so it will directly send the 552
response and everything will work OK with PHP.
Test script:
---
https://bugs.php.net/bug.php?id=62035&edit=1
[PHP-BUG] Bug #62035 [NEW]: Problem with ProFTPd hard quotas
From:
Operating system:
PHP version: 5.4.3
Package: FTP related
Bug Type: Bug
Bug description:Problem with ProFTPd hard quotas
Description:
If you try to upload a file to an FTP account in a ProFTPD server with hard
quotas and available space is less than file size, transfer will be
accepted receiving a "150 Opening BINARY mode data connection for "
response. But as soon as used space reaches quota, ProFTPD will interrupt
transfer sending a "552-Transfer aborted. Disk quota exceeded." message
followed by "552 STOR: notice: quota reached: '' removed".
PHP will know that transfer has failed but will return the first message
("Opening BINARY mode data connection") as error message instead of one of
the 552 real error messages.
If there is no free disk space in FTP account (which can happen if, for
example, you are using ProFTPD soft quotas), ProFTPD will no initially
accept the transfer sending the 150 response, so it will directly send the
552 response and everything will work OK with PHP.
Test script:
---
https://bugs.php.net/bug.php?id=62035&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62035&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62035&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62035&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62035&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62035&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62035&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62035&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62035&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62035&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62035&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62035&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62035&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62035&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62035&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62035&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62035&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62035&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62035&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62035&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62035&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62035&r=mysqlcfg
Req #61602 [Opn->Csd]: Allow access to name of constant used as default value
Edit report at https://bugs.php.net/bug.php?id=61602&edit=1
ID: 61602
Updated by: sebast...@php.net
Reported by:sebast...@php.net
Summary:Allow access to name of constant used as default
value
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:Reflection related
Operating System: Irrelevant
PHP Version:5.4Git-2012-04-02 (Git)
-Assigned To:
+Assigned To:sebastian
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-05-15 07:11:29] sebast...@php.net
Updated example script that uses new method names:
â ~ cat test.php
getParameters();
foreach ($p as $_p) {
var_dump($_p->isDefaultValueConstant());
if ($_p->isDefaultValueConstant()) {
var_dump($_p->getDefaultValueConstantName());
}
}
â ~ php test.php
bool(true)
string(9) "self::bar"
[2012-04-25 06:10:22] sebast...@php.net
Can we at least merge the patch into master? Once it's there we can think about
merging it into PHP 5.4 for PHP 5.4.2.
[2012-04-08 00:45:21] s...@php.net
Not very likely for 5.4.1, doesn't seem to be a critical bug. For 5.4.2, maybe.
[2012-04-03 09:22:42] sebast...@php.net
Any chance this pull request will be merged into PHP 5.4.1? Thanks.
[2012-04-03 06:07:04] reeze dot xia at gmail dot com
PS:
@pierrick pull request is here https://github.com/php/php-src/pull/35.
thanks.
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
https://bugs.php.net/bug.php?id=61602
--
Edit this bug report at https://bugs.php.net/bug.php?id=61602&edit=1
Bug #60761 [Asn->Csd]: zlib.output_compression fails on refresh
Edit report at https://bugs.php.net/bug.php?id=60761&edit=1 ID: 60761 Updated by: m...@php.net Reported by:valentiny510 at yahoo dot es Summary:zlib.output_compression fails on refresh -Status: Assigned +Status: Closed Type: Bug Package:*Compression related Operating System: xp PHP Version:5.4.0RC5 -Assigned To:mattficken +Assigned To:mike Block user comment: N Private report: N New Comment: Should be fixed in 5.4 and master. Previous Comments: [2012-05-15 07:45:37] m...@php.net Automatic comment on behalf of mike Revision: http://git.php.net/?p=php-src.git;a=commit;h=0ad53bfd7da12a92a46c08e3fff579a15026b88b Log: fix bug #60761 zlib.output_compression fails on refresh [2012-05-12 13:42:53] pierre at archlinux dot de I can still reproduce this bug on Arch Linux using PHP 5.4.3 (php-fpm). Which additional information do you guys need? It seems pretty obvious to me. [2012-04-15 02:27:15] adunar at gmail dot com The bug also happens with the cli-server SAPI (both Windows and Ubuntu). Here are a few (bash) commands that will reproduce this bug (assumes zlib.output_compression = On in your php.ini) echo " bug.php php -S 127.0.0.1: > /dev/null 2>&1 & curl --header "Accept-Encoding: gzip" http://localhost:/bug.php 2> /dev/null | wc -m curl --header "Accept-Encoding: gzip" http://localhost:/bug.php 2> /dev/null | wc -m # fg, then ctrl+c to kill php -S If output_compression is working correctly, the two curl commands should print the same number (approx. 16). However with PHP 5.4, the second (and subsequent) curl commands print the size of the original uncompressed output (31). [2012-04-14 23:56:24] adunar at gmail dot com I am experiencing the same problem, using PHP 5.4.0 with the PHP-FPM SAPI on Ubuntu. zlib appears to only compress the output for the first request from a particular worker process. With the default settings it takes a few refreshes to run into the bug. To reproduce immediately, set pm.start_servers = 1 in php-fpm.conf. Afterwards, running "/etc/init.d/php5-fpm reload" allows another request to be compressed before it stops working again. [2012-04-09 12:50:09] paj...@php.net Matt, please take a look at this bug. 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 https://bugs.php.net/bug.php?id=60761 -- Edit this bug report at https://bugs.php.net/bug.php?id=60761&edit=1
Req #61602 [Opn]: Allow access to name of constant used as default value
Edit report at https://bugs.php.net/bug.php?id=61602&edit=1
ID: 61602
Updated by: sebast...@php.net
Reported by:sebast...@php.net
Summary:Allow access to name of constant used as default
value
Status: Open
Type: Feature/Change Request
Package:Reflection related
Operating System: Irrelevant
PHP Version:5.4Git-2012-04-02 (Git)
Block user comment: N
Private report: N
New Comment:
Updated example script that uses new method names:
â ~ cat test.php
getParameters();
foreach ($p as $_p) {
var_dump($_p->isDefaultValueConstant());
if ($_p->isDefaultValueConstant()) {
var_dump($_p->getDefaultValueConstantName());
}
}
â ~ php test.php
bool(true)
string(9) "self::bar"
Previous Comments:
[2012-04-25 06:10:22] sebast...@php.net
Can we at least merge the patch into master? Once it's there we can think about
merging it into PHP 5.4 for PHP 5.4.2.
[2012-04-08 00:45:21] s...@php.net
Not very likely for 5.4.1, doesn't seem to be a critical bug. For 5.4.2, maybe.
[2012-04-03 09:22:42] sebast...@php.net
Any chance this pull request will be merged into PHP 5.4.1? Thanks.
[2012-04-03 06:07:04] reeze dot xia at gmail dot com
PS:
@pierrick pull request is here https://github.com/php/php-src/pull/35.
thanks.
[2012-04-03 05:56:12] reeze dot xia at gmail dot com
Hi, pierrick & sebastian:
I have create another patch for this request. it differ's in:
- rename defaultValueIsConstant to isDefaultValueConstant to match bool
return values's is* method naming.
- handle global constant.
- refactor code to remove duplicate.
- add 3 tests for it.
and I've make test everything looks fine.
please review it for me.
Thanks.
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
https://bugs.php.net/bug.php?id=61602
--
Edit this bug report at https://bugs.php.net/bug.php?id=61602&edit=1
