[PHP-DOC] #40779 [Opn]: error_reporting values in manuals
ID: 40779 User updated by: h dot sim at econ dot usyd dot edu dot au Reported By: h dot sim at econ dot usyd dot edu dot au Status: Open Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: Thanks. The E_ALL value is listed as 2048 only for PHP 4 and PHP 5 in the following manual page. http://au.php.net/manual/en/function.error-reporting.php Once again, thank you. Previous Comments: [2007-03-12 09:22:57] [EMAIL PROTECTED] 2047 is accurate for PHP V5.1x and lower. [2007-03-12 09:18:11] [EMAIL PROTECTED] produces 6143 on PHP 5.2.2-dev (cli) (built: Mar 9 2007 12:07:16) on PHP 6.0.0-dev (cli) (built: Jan 8 2007 10:28:23), the value is 8191 These 2 values are accurate with regards to the documentation (E_STRICT was added in PHP6, so 6143 + 2048 = 8191). There are 2 issues here. 1 - The E_ALL encompasses new errorlevels as new versions of PHP are developed. 2 - Documentation is not always uptodate outside of the English version. In this instance, the non-english pages have not been updated with the new errorlevels. [2007-03-11 22:30:15] h dot sim at econ dot usyd dot edu dot au Description: E_ALL value is 6143 in the following URL http://au.php.net/manual/en/function.error-reporting.php E_ALL value is 2047 in the following URLs http://au.php.net/manual/de/function.error-reporting.php http://au.php.net/manual/sk/function.error-reporting.php http://au.php.net/manual/nl/function.error-reporting.php http://au.php.net/manual/es/function.error-reporting.php http://au.php.net/manual/pt_BR/function.error-reporting.php Which one is correct? Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/?id=40779&edit=1
Re: [PHP-DOC] grep -ri ' a [aeiou]'... correcting or ignoring?
Martin Samesch wrote:
> Hi,
>
> grep -ri ' a [aeiou]'... gets a lot of hits. Should they be
> corrected or not?
Most of these are hard-vowel sounds, so "a user" (for example) is correct.
I see a few places where there are mistakes ("a Apache" for example),
though, and yes, those should be fixed.
(hopefully this will actually go through without my mail client eating
it this time. Sorry if this shows up double/triple)
S
[PHP-DOC] #37706 [Opn->Csd]: oci8 maps to same descriptor when fetching multiple rows with lobs
ID: 37706 Updated by: [EMAIL PROTECTED] Reported By: crescentfreshpot at yahoo dot com -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Win XP PHP Version: 5CVS-2006-06-05 (snap) Previous Comments: [2006-06-06 12:48:45] [EMAIL PROTECTED] Sure. Feel free to send a patch for the docs. [2006-06-06 12:45:11] crescentfreshpot at yahoo dot com Well it was not obvious that all my fetched rows would all point to the same (last fetched) lob descriptor in underlying memory, so can we say this at least needs to be documented? [2006-06-06 06:36:54] [EMAIL PROTECTED] I don't see any way to bind several variables to one placeholder/column in OCI API, so we reuse the same descriptor on each iteration. [2006-06-06 00:29:57] crescentfreshpot at yahoo dot com Three things: a) AFAIK php has no problems with having multiple stream handles open, so does your "it's expected" comment refer to limitations in the oci library itself? b) is this why there is no way to stop oci_fetch_all from automatically fetching my lob data and instead return them to me as separate, *individual* streams? b) Is there no workaround for this? Something along the lines of php_stream_copy_to_stream to save a reference to an oci stream as it's fetched say in a fetchAll scenario? [2006-06-05 22:21:38] [EMAIL PROTECTED] $row1[0] and $row2[0] are different variables pointing to the same LOB descriptor. This is how it works and it's 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 http://bugs.php.net/37706 -- Edit this bug report at http://bugs.php.net/?id=37706&edit=1
[PHP-DOC] grep -ri ' a [aeiou]'... correcting or ignoring?
Hi, grep -ri ' a [aeiou]'... gets a lot of hits. Should they be corrected or not? Cheers, Martin
[PHP-DOC] #40778 [Opn]: Cookies with secure parameter sent via HTTP
ID: 40778
Updated by: [EMAIL PROTECTED]
Reported By: mbowie at buzmo dot com
Status: Open
-Bug Type: Session related
+Bug Type: Documentation problem
Operating System: FreeBSD 6.0R
PHP Version: 5.2.1
New Comment:
Secure
OPTIONAL. The Secure attribute (with no value) directs the user
agent to use only (unspecified) secure means to contact the origin
server whenever it sends back this cookie, to protect the
confidentially and authenticity of the information in the cookie.
The user agent (possibly with user interaction) MAY determine what
level of security it considers appropriate for "secure" cookies.
The Secure attribute should be considered security advice from the
server to the user agent, indicating that it is in the session's
interest to protect the cookie contents. When it sends a "secure"
cookie back to a server, the user agent SHOULD use no less than
the same level of security as was used when it received the cookie
from the server.
http://www.faqs.org/rfcs/rfc2965.html
Previous Comments:
[2007-03-11 22:20:48] mbowie at buzmo dot com
Description:
Cookies sent via the set_cookie method or via PHP's session module with
the secure parameter set to true can be sent via HTTP.
http://php.net/set_cookie has notes against the secure flag which
states : "Indicates that the cookie should only be transmitted over a
secure HTTPS connection. When set to TRUE, the cookie will only be set
if a secure connection exists. The default is FALSE.". This does not
appear to be the case.
It's possible that this is by design, but if so, perhaps it's worth
noting on the documentation at the secure parameter only refers to the
browser's activities, not those of the webserver.
The upshot of this is that an attacker may pickup a visitor's cookie by
sniffing HTTP traffic on the wire and craft their own cookie in order to
spoof the visitor's identity on the secure side.
The same thing happens on 4.3.9, 5.2.0 and 5.2.1; all of which are
compiled via the FreeBSD ports tree and are running on various flavors
of FreeBSD.
Reproduce code:
---
$domain = 'setme';
setcookie('setcookie', 'insecure', time()+3600, '/', $domain, true);
session_name('session_set_cookie_params');
session_set_cookie_params(
time()+3600,
'/',
$domain,
true
);
session_start();
Expected result:
No cookies should be sent to the browser unless the page is requested
via an SSL encrypted channel.
Actual result:
--
Cookie headers are sent regardless of whether the page is requested via
HTTP or HTTPS.
--
Edit this bug report at http://bugs.php.net/?id=40778&edit=1
[PHP-DOC] #40779 [Opn]: error_reporting values in manuals
ID: 40779 Updated by: [EMAIL PROTECTED] Reported By: h dot sim at econ dot usyd dot edu dot au Status: Open Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: 2047 is accurate for PHP V5.1x and lower. Previous Comments: [2007-03-12 09:18:11] [EMAIL PROTECTED] produces 6143 on PHP 5.2.2-dev (cli) (built: Mar 9 2007 12:07:16) on PHP 6.0.0-dev (cli) (built: Jan 8 2007 10:28:23), the value is 8191 These 2 values are accurate with regards to the documentation (E_STRICT was added in PHP6, so 6143 + 2048 = 8191). There are 2 issues here. 1 - The E_ALL encompasses new errorlevels as new versions of PHP are developed. 2 - Documentation is not always uptodate outside of the English version. In this instance, the non-english pages have not been updated with the new errorlevels. [2007-03-11 22:30:15] h dot sim at econ dot usyd dot edu dot au Description: E_ALL value is 6143 in the following URL http://au.php.net/manual/en/function.error-reporting.php E_ALL value is 2047 in the following URLs http://au.php.net/manual/de/function.error-reporting.php http://au.php.net/manual/sk/function.error-reporting.php http://au.php.net/manual/nl/function.error-reporting.php http://au.php.net/manual/es/function.error-reporting.php http://au.php.net/manual/pt_BR/function.error-reporting.php Which one is correct? Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/?id=40779&edit=1
[PHP-DOC] #40779 [Opn]: error_reporting values in manuals
ID: 40779 Updated by: [EMAIL PROTECTED] Reported By: h dot sim at econ dot usyd dot edu dot au Status: Open Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: produces 6143 on PHP 5.2.2-dev (cli) (built: Mar 9 2007 12:07:16) on PHP 6.0.0-dev (cli) (built: Jan 8 2007 10:28:23), the value is 8191 These 2 values are accurate with regards to the documentation (E_STRICT was added in PHP6, so 6143 + 2048 = 8191). There are 2 issues here. 1 - The E_ALL encompasses new errorlevels as new versions of PHP are developed. 2 - Documentation is not always uptodate outside of the English version. In this instance, the non-english pages have not been updated with the new errorlevels. Previous Comments: [2007-03-11 22:30:15] h dot sim at econ dot usyd dot edu dot au Description: E_ALL value is 6143 in the following URL http://au.php.net/manual/en/function.error-reporting.php E_ALL value is 2047 in the following URLs http://au.php.net/manual/de/function.error-reporting.php http://au.php.net/manual/sk/function.error-reporting.php http://au.php.net/manual/nl/function.error-reporting.php http://au.php.net/manual/es/function.error-reporting.php http://au.php.net/manual/pt_BR/function.error-reporting.php Which one is correct? Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/?id=40779&edit=1
