[PHP-DOC] #36710 [Opn]: self-contradictory documentation of escaping in single-quoted strings
ID: 36710 User updated by: swift at alum dot mit dot edu Reported By: swift at alum dot mit dot edu Status: Open Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: Argh! This web interface told me I could "edit my submission". That's not fully true, since I can't edit the main text, I can only add to it. So I've now posted two long discussions that differ only by a pair of commas, and I have no way to correct that. The second submission contains the corrected punctuation. Previous Comments: [2006-03-13 04:48:51] swift at alum dot mit dot edu I quote from the node on strings in the PHP manual (www.php.net/manual/en/language.types.string.php) where it discusses single-quoted strings: I break into sentences which I reference below: (1) To specify a literal single quote, you will need to escape it with a backslash (\), like in many other languages. (2) If a backslash needs to occur before a single quote or at the end of the string, you need to double it. (3) Note that if you try to escape any other character, the backslash will also be printed! (4) So usually there is no need to escape the backslash itself. Sentence (1) is clear, though "will" should be omitted for better clarity. Sentence (2) means that a literal backslash needs to be escaped in only two cases: when it appears before a literal single quote and when it is the last character of the string. This is of course incorrect (it is contradicted by a correct example further down the page whose output is 'You deleted C:\*.*?'). What the author intends to say is much better expressed by the following: "An escaped backslash (\\) likewise specifies a literal backslash, but it is not normally necessary to escape a literal backslash. Escaping a backslash is necessary only when the context would otherwise make the backslash into an escape operator -- that is, when it appears immediately before another backslash or the single quote terminating the string." Sentence (3) is unclear because it is unclear whether the reference of "other" is "backslash" or "single quote" or both. Also "try to escape" is a confusing hypothetical. A good revision would be: "A backslash followed by any character besides a single quote or another backslash is a literal backslash." Sentence (4) is confusing because it's not clear that "the backslash itself" refers to a literal backslash or an escape-operator backslash. Omit this sentence: this section should deal only with how to specify a single quoted string. Discussion of applications of strings (such as regexps) which also use the backslash as an escape operator belongs somewhere else -- or at least should be clearly separate from the discussion of simply how to specify the contents of a string. "Stringing" together the suggested revisions above: To specify a literal single quote, you need to escape it with a backslash (\), like in many other languages. An escaped backslash (\\) likewise specifies a literal backslash, but it is not normally necessary to escape a literal backslash. Escaping a backslash is necessary only when the context would otherwise make the backslash into an escape operator -- that is, when it appears immediately before another backslash or the single quote terminating the string. A backslash followed by any character besides a single quote or another backslash is a literal backslash. [2006-03-13 04:43:22] swift at alum dot mit dot edu Description: I quote from the node on strings in the PHP manual (www.php.net/manual/en/language.types.string.php) where it discusses single-quoted strings: I break into sentences which I reference below: (1) To specify a literal single quote, you will need to escape it with a backslash (\), like in many other languages. (2) If a backslash needs to occur before a single quote or at the end of the string, you need to double it. (3) Note that if you try to escape any other character, the backslash will also be printed! (4) So usually there is no need to escape the backslash itself. Sentence (1) is clear, though "will" should be omitted for better clarity. Sentence (2) means that a literal backslash needs to be escaped in only two cases: when it appears before a literal single quote and when it is the last character of the string. This is of course incorrect (it is contradicted by a correct example further down the page whose output is 'You deleted C:\*.*?'). What the author intends to say is much better expressed by the following: "An escaped backslash (\\) likewise specifies a literal backslash, but it is not normally necessary to escape a literal backslash. Escaping a backslash is necessary only when the context would otherwise make the backslash into an escape operator
[PHP-DOC] #36710 [Opn]: self-contradictory documentation of escaping in single-quoted strings
ID: 36710 User updated by: swift at alum dot mit dot edu Reported By: swift at alum dot mit dot edu Status: Open Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: I quote from the node on strings in the PHP manual (www.php.net/manual/en/language.types.string.php) where it discusses single-quoted strings: I break into sentences which I reference below: (1) To specify a literal single quote, you will need to escape it with a backslash (\), like in many other languages. (2) If a backslash needs to occur before a single quote or at the end of the string, you need to double it. (3) Note that if you try to escape any other character, the backslash will also be printed! (4) So usually there is no need to escape the backslash itself. Sentence (1) is clear, though "will" should be omitted for better clarity. Sentence (2) means that a literal backslash needs to be escaped in only two cases: when it appears before a literal single quote and when it is the last character of the string. This is of course incorrect (it is contradicted by a correct example further down the page whose output is 'You deleted C:\*.*?'). What the author intends to say is much better expressed by the following: "An escaped backslash (\\) likewise specifies a literal backslash, but it is not normally necessary to escape a literal backslash. Escaping a backslash is necessary only when the context would otherwise make the backslash into an escape operator -- that is, when it appears immediately before another backslash or the single quote terminating the string." Sentence (3) is unclear because it is unclear whether the reference of "other" is "backslash" or "single quote" or both. Also "try to escape" is a confusing hypothetical. A good revision would be: "A backslash followed by any character besides a single quote or another backslash is a literal backslash." Sentence (4) is confusing because it's not clear that "the backslash itself" refers to a literal backslash or an escape-operator backslash. Omit this sentence: this section should deal only with how to specify a single quoted string. Discussion of applications of strings (such as regexps) which also use the backslash as an escape operator belongs somewhere else -- or at least should be clearly separate from the discussion of simply how to specify the contents of a string. "Stringing" together the suggested revisions above: To specify a literal single quote, you need to escape it with a backslash (\), like in many other languages. An escaped backslash (\\) likewise specifies a literal backslash, but it is not normally necessary to escape a literal backslash. Escaping a backslash is necessary only when the context would otherwise make the backslash into an escape operator -- that is, when it appears immediately before another backslash or the single quote terminating the string. A backslash followed by any character besides a single quote or another backslash is a literal backslash. Previous Comments: [2006-03-13 04:43:22] swift at alum dot mit dot edu Description: I quote from the node on strings in the PHP manual (www.php.net/manual/en/language.types.string.php) where it discusses single-quoted strings: I break into sentences which I reference below: (1) To specify a literal single quote, you will need to escape it with a backslash (\), like in many other languages. (2) If a backslash needs to occur before a single quote or at the end of the string, you need to double it. (3) Note that if you try to escape any other character, the backslash will also be printed! (4) So usually there is no need to escape the backslash itself. Sentence (1) is clear, though "will" should be omitted for better clarity. Sentence (2) means that a literal backslash needs to be escaped in only two cases: when it appears before a literal single quote and when it is the last character of the string. This is of course incorrect (it is contradicted by a correct example further down the page whose output is 'You deleted C:\*.*?'). What the author intends to say is much better expressed by the following: "An escaped backslash (\\) likewise specifies a literal backslash, but it is not normally necessary to escape a literal backslash. Escaping a backslash is necessary only when the context would otherwise make the backslash into an escape operator -- that is when it appears immediately before another backslash or the single quote terminating the string." Sentence (3) is unclear because it is unclear whether the reference of "other" is "backslash" or "single quote" or both. Also "try to escape" is a confusing hypothetical. A good revision would be: "A backslash followed by any character besides a single quote or another backslash is a literal backslash." Sentence (4) is confusing
[PHP-DOC] #36710 [NEW]: self-contradictory documentation of escaping in single-quoted strings
From: swift at alum dot mit dot edu Operating system: Irrelevant PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: self-contradictory documentation of escaping in single-quoted strings Description: I quote from the node on strings in the PHP manual (www.php.net/manual/en/language.types.string.php) where it discusses single-quoted strings: I break into sentences which I reference below: (1) To specify a literal single quote, you will need to escape it with a backslash (\), like in many other languages. (2) If a backslash needs to occur before a single quote or at the end of the string, you need to double it. (3) Note that if you try to escape any other character, the backslash will also be printed! (4) So usually there is no need to escape the backslash itself. Sentence (1) is clear, though "will" should be omitted for better clarity. Sentence (2) means that a literal backslash needs to be escaped in only two cases: when it appears before a literal single quote and when it is the last character of the string. This is of course incorrect (it is contradicted by a correct example further down the page whose output is 'You deleted C:\*.*?'). What the author intends to say is much better expressed by the following: "An escaped backslash (\\) likewise specifies a literal backslash, but it is not normally necessary to escape a literal backslash. Escaping a backslash is necessary only when the context would otherwise make the backslash into an escape operator -- that is when it appears immediately before another backslash or the single quote terminating the string." Sentence (3) is unclear because it is unclear whether the reference of "other" is "backslash" or "single quote" or both. Also "try to escape" is a confusing hypothetical. A good revision would be: "A backslash followed by any character besides a single quote or another backslash is a literal backslash." Sentence (4) is confusing because it's not clear that "the backslash itself" refers to a literal backslash or an escape-operator backslash. Omit this sentence: this section should deal only with how to specify a single quoted string. Discussion of applications of strings (such as regexps) which also use the backslash as an escape operator belongs somewhere else -- or at least should be clearly separate from the discussion of simply how to specify the contents of a string. "Stringing" together the suggested revisions above: To specify a literal single quote, you need to escape it with a backslash (\), like in many other languages. An escaped backslash (\\) likewise specifies a literal backslash, but it is not normally necessary to escape a literal backslash. Escaping a backslash is necessary only when the context would otherwise make the backslash into an escape operator -- that is when it appears immediately before another backslash or the single quote terminating the string. A backslash followed by any character besides a single quote or another backslash is a literal backslash. -- Edit bug report at http://bugs.php.net/?id=36710&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36710&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36710&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36710&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36710&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36710&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36710&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36710&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36710&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36710&r=support Expected behavior:http://bugs.php.net/fix.php?id=36710&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36710&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36710&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36710&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36710&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36710&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36710&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36710&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36710&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36710&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36710&r=mysqlcfg
[PHP-DOC] #36705 [Com]: Location header results in duplicate Status header ([f]cgi only)
ID: 36705
Comment by: judas dot iscariote at gmail dot com
Reported By: alisencer at gmail dot com
Status: Open
Bug Type: Documentation problem
Operating System: FreeBSD
PHP Version: 5.1.2
New Comment:
as an effective workaround to this problem, you can use PEAR
HTTP_Header class.
hint : method sendStatusCode()
Previous Comments:
[2006-03-12 19:39:18] ali dot sencer at gmail dot com
> and we can't do anything about Apache changing its behaviour.
I hadn't considered that, sorry. And thank you for taking the time.
> Why don't you just send the appropriate status header with
> the header() call?
The issue is, we send a Status: 200 very early to override the 404
(from the error-handler). After that the code branches in many
different ways, and plugins and extensions sometimes make changes to
(i.e. replace) the Status-code as well. Given that in some situations
we need to use a Location-header, we now have to make sure that nobody
has ever used "Status: " before.
So, yeah we can workaround this, but the situation as it is, is
everything but intuitive. I guess we'll have to make do
[2006-03-12 19:02:26] [EMAIL PROTECTED]
I can't find a single evidence that a "Status:" header is treated
differently than any other header in PHP versions 4.3, 4.4 and 5.1 --
and we can't do anything about Apache changing its behaviour.
Why don't you just send the appropriate status header with the header()
call?
header("Location: uri", 1, 301);
[2006-03-12 18:29:38] ali dot sencer at gmail dot com
We had definitive, reproducable bug-reports for our php-application,
where sending HTTP/1.1 ... type status-codes was ignored. In fact, if
you read the comments on this page:
http://de.php.net/manual/en/function.header.php
you will find several people noting that HTTP/1.x doesn't work with
CGI.
In fact here is something reproducable:
- use this in your .htaccess:
ErrorDocument 404 /test.php
- then call an invalid url
- the response code will be 404 (fine). Try setting the Status code
with header("HTTP/1.1 200"); it won't work (it still returns a 404),
but using header("Status: 200"); yields the desired result and returns
a 200. So obviously saying always use HTTP/1.x and never use Status:
doesn't work in reality.
To let you know where we're coming from: At this point we've come full
circle:
1) We used only HTTP/1.x when starting out. Then moved
2) to use both HTTP/1.x and Status: at the same time, then
3) to use HTTP/1.x and Status: depending on sapi_name,
4) and now back to only using HTTP/1.x
always user-complaints would drive the changes, and each time it would
fix it for some and break it for others.
[2006-03-12 17:22:23] [EMAIL PROTECTED]
It's even that way in PHP-4.
[2006-03-12 16:29:20] ali dot sencer at gmail dot com
download and tried it (php5.1-200603121330)
$ ./php -v
PHP 5.1.3RC2-dev (cgi-fcgi) (built: Feb 20 2006 15:24:12)
...
[EMAIL PROTECTED]:~/php5.1-200603121330/sapi/cgi$ echo "http://www.example.org' );?>" | ./php
Status: 302
X-Powered-By: PHP/5.1.3RC2-dev
Status: 301
Location: http://www.example.org
Content-type: text/html
The bug is still present.
> One should not use "Status: 123" but "HTTP/1.x 123".
Did I miss an announcement? Since when is that? Using HTTP/1.x type
headers was not working on a variety of systems with (f)cgi, which is
why the following snippet was introduced (which is in a lot of
applications):
if (substr(php_sapi_name(), 0, 3) == 'cgi')
header("Status: $status");
else
header("HTTP/1.1 $status");
(which was the only solution that worked on all systems - until some
recent changes in newer releases.)
I could have sworn this was somehwere in the documentation even. So in
which versions was this changed? How can portable applications in PHP
be written, if these things change silently every now and then.
Why can header("Status: ") be used at all, if it's not supposed to be
used?
Can the behaviour at least be "fixed" in such a way, that (f)cgi won't
send "Status: " twice, which results in a 500 error by the webserver.
Thanks.
[edit: I am the bug-submitter, but must have mistyped my password]
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/36705
--
Edit this bug report at http://bugs.php.net/?id=36705&edit=1
Re: [PHP-DOC] #30185 [Com]: Documentation for native interfaces
OK I might look into this if no-one beats me to it. -- Gavin Foster On 11 Mar 2006, at 21:27, [EMAIL PROTECTED] wrote: The last comment is quite old: is the plan still to incorporate http://www.php.net/~helly/php/ext/spl/ into an Appendix? Yes. Jakub Vrana
Re: [PHP-DOC] #30185 [Com]: Documentation for native interfaces
> The last comment is quite old: is the plan still to > incorporate > http://www.php.net/~helly/php/ext/spl/ > into an Appendix? Yes. Jakub Vrana
[PHP-DOC] #36705 [Com]: Location header results in duplicate Status header ([f]cgi only)
ID: 36705
Comment by: ali dot sencer at gmail dot com
Reported By: alisencer at gmail dot com
Status: Open
Bug Type: Documentation problem
Operating System: FreeBSD
PHP Version: 5.1.2
New Comment:
> and we can't do anything about Apache changing its behaviour.
I hadn't considered that, sorry. And thank you for taking the time.
> Why don't you just send the appropriate status header with
> the header() call?
The issue is, we send a Status: 200 very early to override the 404
(from the error-handler). After that the code branches in many
different ways, and plugins and extensions sometimes make changes to
(i.e. replace) the Status-code as well. Given that in some situations
we need to use a Location-header, we now have to make sure that nobody
has ever used "Status: " before.
So, yeah we can workaround this, but the situation as it is, is
everything but intuitive. I guess we'll have to make do
Previous Comments:
[2006-03-12 19:02:26] [EMAIL PROTECTED]
I can't find a single evidence that a "Status:" header is treated
differently than any other header in PHP versions 4.3, 4.4 and 5.1 --
and we can't do anything about Apache changing its behaviour.
Why don't you just send the appropriate status header with the header()
call?
header("Location: uri", 1, 301);
[2006-03-12 18:29:38] ali dot sencer at gmail dot com
We had definitive, reproducable bug-reports for our php-application,
where sending HTTP/1.1 ... type status-codes was ignored. In fact, if
you read the comments on this page:
http://de.php.net/manual/en/function.header.php
you will find several people noting that HTTP/1.x doesn't work with
CGI.
In fact here is something reproducable:
- use this in your .htaccess:
ErrorDocument 404 /test.php
- then call an invalid url
- the response code will be 404 (fine). Try setting the Status code
with header("HTTP/1.1 200"); it won't work (it still returns a 404),
but using header("Status: 200"); yields the desired result and returns
a 200. So obviously saying always use HTTP/1.x and never use Status:
doesn't work in reality.
To let you know where we're coming from: At this point we've come full
circle:
1) We used only HTTP/1.x when starting out. Then moved
2) to use both HTTP/1.x and Status: at the same time, then
3) to use HTTP/1.x and Status: depending on sapi_name,
4) and now back to only using HTTP/1.x
always user-complaints would drive the changes, and each time it would
fix it for some and break it for others.
[2006-03-12 17:22:23] [EMAIL PROTECTED]
It's even that way in PHP-4.
[2006-03-12 16:29:20] ali dot sencer at gmail dot com
download and tried it (php5.1-200603121330)
$ ./php -v
PHP 5.1.3RC2-dev (cgi-fcgi) (built: Feb 20 2006 15:24:12)
...
[EMAIL PROTECTED]:~/php5.1-200603121330/sapi/cgi$ echo "http://www.example.org' );?>" | ./php
Status: 302
X-Powered-By: PHP/5.1.3RC2-dev
Status: 301
Location: http://www.example.org
Content-type: text/html
The bug is still present.
> One should not use "Status: 123" but "HTTP/1.x 123".
Did I miss an announcement? Since when is that? Using HTTP/1.x type
headers was not working on a variety of systems with (f)cgi, which is
why the following snippet was introduced (which is in a lot of
applications):
if (substr(php_sapi_name(), 0, 3) == 'cgi')
header("Status: $status");
else
header("HTTP/1.1 $status");
(which was the only solution that worked on all systems - until some
recent changes in newer releases.)
I could have sworn this was somehwere in the documentation even. So in
which versions was this changed? How can portable applications in PHP
be written, if these things change silently every now and then.
Why can header("Status: ") be used at all, if it's not supposed to be
used?
Can the behaviour at least be "fixed" in such a way, that (f)cgi won't
send "Status: " twice, which results in a 500 error by the webserver.
Thanks.
[edit: I am the bug-submitter, but must have mistyped my password]
[2006-03-12 15:55:22] [EMAIL PROTECTED]
Recalssifying as a documentation problem.
One should not use "Status: 123" but "HTTP/1.x 123".
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/36705
--
Edit this bug report at http://bugs.php.net/?id=36705&edit=1
[PHP-DOC] #36705 [Opn]: Location header results in duplicate Status header ([f]cgi only)
ID: 36705
Updated by: [EMAIL PROTECTED]
Reported By: alisencer at gmail dot com
Status: Open
Bug Type: Documentation problem
Operating System: FreeBSD
PHP Version: 5.1.2
New Comment:
I can't find a single evidence that a "Status:" header is treated
differently than any other header in PHP versions 4.3, 4.4 and 5.1 --
and we can't do anything about Apache changing its behaviour.
Why don't you just send the appropriate status header with the header()
call?
header("Location: uri", 1, 301);
Previous Comments:
[2006-03-12 18:29:38] ali dot sencer at gmail dot com
We had definitive, reproducable bug-reports for our php-application,
where sending HTTP/1.1 ... type status-codes was ignored. In fact, if
you read the comments on this page:
http://de.php.net/manual/en/function.header.php
you will find several people noting that HTTP/1.x doesn't work with
CGI.
In fact here is something reproducable:
- use this in your .htaccess:
ErrorDocument 404 /test.php
- then call an invalid url
- the response code will be 404 (fine). Try setting the Status code
with header("HTTP/1.1 200"); it won't work (it still returns a 404),
but using header("Status: 200"); yields the desired result and returns
a 200. So obviously saying always use HTTP/1.x and never use Status:
doesn't work in reality.
To let you know where we're coming from: At this point we've come full
circle:
1) We used only HTTP/1.x when starting out. Then moved
2) to use both HTTP/1.x and Status: at the same time, then
3) to use HTTP/1.x and Status: depending on sapi_name,
4) and now back to only using HTTP/1.x
always user-complaints would drive the changes, and each time it would
fix it for some and break it for others.
[2006-03-12 17:22:23] [EMAIL PROTECTED]
It's even that way in PHP-4.
[2006-03-12 16:29:20] ali dot sencer at gmail dot com
download and tried it (php5.1-200603121330)
$ ./php -v
PHP 5.1.3RC2-dev (cgi-fcgi) (built: Feb 20 2006 15:24:12)
...
[EMAIL PROTECTED]:~/php5.1-200603121330/sapi/cgi$ echo "http://www.example.org' );?>" | ./php
Status: 302
X-Powered-By: PHP/5.1.3RC2-dev
Status: 301
Location: http://www.example.org
Content-type: text/html
The bug is still present.
> One should not use "Status: 123" but "HTTP/1.x 123".
Did I miss an announcement? Since when is that? Using HTTP/1.x type
headers was not working on a variety of systems with (f)cgi, which is
why the following snippet was introduced (which is in a lot of
applications):
if (substr(php_sapi_name(), 0, 3) == 'cgi')
header("Status: $status");
else
header("HTTP/1.1 $status");
(which was the only solution that worked on all systems - until some
recent changes in newer releases.)
I could have sworn this was somehwere in the documentation even. So in
which versions was this changed? How can portable applications in PHP
be written, if these things change silently every now and then.
Why can header("Status: ") be used at all, if it's not supposed to be
used?
Can the behaviour at least be "fixed" in such a way, that (f)cgi won't
send "Status: " twice, which results in a 500 error by the webserver.
Thanks.
[edit: I am the bug-submitter, but must have mistyped my password]
[2006-03-12 15:55:22] [EMAIL PROTECTED]
Recalssifying as a documentation problem.
One should not use "Status: 123" but "HTTP/1.x 123".
[2006-03-12 15:39:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
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/36705
--
Edit this bug report at http://bugs.php.net/?id=36705&edit=1
[PHP-DOC] #36705 [Com]: Location header results in duplicate Status header ([f]cgi only)
ID: 36705
Comment by: ali dot sencer at gmail dot com
Reported By: alisencer at gmail dot com
Status: Open
Bug Type: Documentation problem
Operating System: FreeBSD
PHP Version: 5.1.2
New Comment:
We had definitive, reproducable bug-reports for our php-application,
where sending HTTP/1.1 ... type status-codes was ignored. In fact, if
you read the comments on this page:
http://de.php.net/manual/en/function.header.php
you will find several people noting that HTTP/1.x doesn't work with
CGI.
In fact here is something reproducable:
- use this in your .htaccess:
ErrorDocument 404 /test.php
- then call an invalid url
- the response code will be 404 (fine). Try setting the Status code
with header("HTTP/1.1 200"); it won't work (it still returns a 404),
but using header("Status: 200"); yields the desired result and returns
a 200. So obviously saying always use HTTP/1.x and never use Status:
doesn't work in reality.
To let you know where we're coming from: At this point we've come full
circle:
1) We used only HTTP/1.x when starting out. Then moved
2) to use both HTTP/1.x and Status: at the same time, then
3) to use HTTP/1.x and Status: depending on sapi_name,
4) and now back to only using HTTP/1.x
always user-complaints would drive the changes, and each time it would
fix it for some and break it for others.
Previous Comments:
[2006-03-12 17:22:23] [EMAIL PROTECTED]
It's even that way in PHP-4.
[2006-03-12 16:29:20] ali dot sencer at gmail dot com
download and tried it (php5.1-200603121330)
$ ./php -v
PHP 5.1.3RC2-dev (cgi-fcgi) (built: Feb 20 2006 15:24:12)
...
[EMAIL PROTECTED]:~/php5.1-200603121330/sapi/cgi$ echo "http://www.example.org' );?>" | ./php
Status: 302
X-Powered-By: PHP/5.1.3RC2-dev
Status: 301
Location: http://www.example.org
Content-type: text/html
The bug is still present.
> One should not use "Status: 123" but "HTTP/1.x 123".
Did I miss an announcement? Since when is that? Using HTTP/1.x type
headers was not working on a variety of systems with (f)cgi, which is
why the following snippet was introduced (which is in a lot of
applications):
if (substr(php_sapi_name(), 0, 3) == 'cgi')
header("Status: $status");
else
header("HTTP/1.1 $status");
(which was the only solution that worked on all systems - until some
recent changes in newer releases.)
I could have sworn this was somehwere in the documentation even. So in
which versions was this changed? How can portable applications in PHP
be written, if these things change silently every now and then.
Why can header("Status: ") be used at all, if it's not supposed to be
used?
Can the behaviour at least be "fixed" in such a way, that (f)cgi won't
send "Status: " twice, which results in a 500 error by the webserver.
Thanks.
[edit: I am the bug-submitter, but must have mistyped my password]
[2006-03-12 15:55:22] [EMAIL PROTECTED]
Recalssifying as a documentation problem.
One should not use "Status: 123" but "HTTP/1.x 123".
[2006-03-12 15:39:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-12 14:14:36] alisencer at gmail dot com
Description:
In php-fastcgi, a header("Location: ..") call always results in an
additional "Status:" header. This causes the web server to throw a 500
Internal server error.
Identical code works perfectly in mod_php. The problem is specific to
fastcgi.
It doesn't matter what Status code the first header() call sends; the
"Location:" call always adds a second "Status: 302" line.
The effect is, that it becomes impossible to use
header("Location;..."), if at any previous point in the script a Status
header has been sent. It is also contrary to what the documentation
says:
http://de.php.net/manual/en/function.header.php
"The second special case is the "Location:" header. Not only does it
send this header back to the browser, but it also returns a REDIRECT
(302) status code to the browser unless some 3xx status code has
already been set."
(Note the last part of that paragraph)
Related: This seems to be what was happening in this bug report as
well: http://bugs.php.net/bug.php?id=33225 which unfortunately was
closed as bogus.
Reproduce code:
---
$ echo "http://www.example.org' );?>" | php/php-fastcgi/php5-fcgi
Expected result:
Content-type: text/html; charset=UTF-8
Status: 301
Location: http://www.example.com
Actual result:
--
Status: 302
Content-type: text/html; charset=U
[PHP-DOC] #36705 [Opn]: Location header results in duplicate Status header ([f]cgi only)
ID: 36705
Updated by: [EMAIL PROTECTED]
Reported By: alisencer at gmail dot com
Status: Open
Bug Type: Documentation problem
Operating System: FreeBSD
PHP Version: 5.1.2
New Comment:
It's even that way in PHP-4.
Previous Comments:
[2006-03-12 16:29:20] ali dot sencer at gmail dot com
download and tried it (php5.1-200603121330)
$ ./php -v
PHP 5.1.3RC2-dev (cgi-fcgi) (built: Feb 20 2006 15:24:12)
...
[EMAIL PROTECTED]:~/php5.1-200603121330/sapi/cgi$ echo "http://www.example.org' );?>" | ./php
Status: 302
X-Powered-By: PHP/5.1.3RC2-dev
Status: 301
Location: http://www.example.org
Content-type: text/html
The bug is still present.
> One should not use "Status: 123" but "HTTP/1.x 123".
Did I miss an announcement? Since when is that? Using HTTP/1.x type
headers was not working on a variety of systems with (f)cgi, which is
why the following snippet was introduced (which is in a lot of
applications):
if (substr(php_sapi_name(), 0, 3) == 'cgi')
header("Status: $status");
else
header("HTTP/1.1 $status");
(which was the only solution that worked on all systems - until some
recent changes in newer releases.)
I could have sworn this was somehwere in the documentation even. So in
which versions was this changed? How can portable applications in PHP
be written, if these things change silently every now and then.
Why can header("Status: ") be used at all, if it's not supposed to be
used?
Can the behaviour at least be "fixed" in such a way, that (f)cgi won't
send "Status: " twice, which results in a 500 error by the webserver.
Thanks.
[edit: I am the bug-submitter, but must have mistyped my password]
[2006-03-12 15:55:22] [EMAIL PROTECTED]
Recalssifying as a documentation problem.
One should not use "Status: 123" but "HTTP/1.x 123".
[2006-03-12 15:39:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-12 14:14:36] alisencer at gmail dot com
Description:
In php-fastcgi, a header("Location: ..") call always results in an
additional "Status:" header. This causes the web server to throw a 500
Internal server error.
Identical code works perfectly in mod_php. The problem is specific to
fastcgi.
It doesn't matter what Status code the first header() call sends; the
"Location:" call always adds a second "Status: 302" line.
The effect is, that it becomes impossible to use
header("Location;..."), if at any previous point in the script a Status
header has been sent. It is also contrary to what the documentation
says:
http://de.php.net/manual/en/function.header.php
"The second special case is the "Location:" header. Not only does it
send this header back to the browser, but it also returns a REDIRECT
(302) status code to the browser unless some 3xx status code has
already been set."
(Note the last part of that paragraph)
Related: This seems to be what was happening in this bug report as
well: http://bugs.php.net/bug.php?id=33225 which unfortunately was
closed as bogus.
Reproduce code:
---
$ echo "http://www.example.org' );?>" | php/php-fastcgi/php5-fcgi
Expected result:
Content-type: text/html; charset=UTF-8
Status: 301
Location: http://www.example.com
Actual result:
--
Status: 302
Content-type: text/html; charset=UTF-8
Status: 301
Location: http://www.example.com
--
Edit this bug report at http://bugs.php.net/?id=36705&edit=1
[PHP-DOC] #36112 [Asn]: preg_replace example suggests poor patterns, which are harmful if really used
ID: 36112
Updated by: [EMAIL PROTECTED]
Reported By: pornel at despammed dot com
Status: Assigned
Bug Type:Documentation problem
PHP Version: Irrelevant
Assigned To: gavinfo
New Comment:
There are lot of inconsistencies in this example:
1) About @]*?>.*?@si :
a) the first ? is useless.
2) About @<[\/\!]*?[^<>]*?>@si :
a) / and ! don't have to be escaped.
b) [\/\!]*? is useless, as it's already matched by [^<>]*?.
c) the ? of [^<>]*? is useless.
d) the PCRE_DOTALL modifier is useless, there is no dot.
e) the PCRE_CASELESS modifier is useless.
f) what is the point avoiding "<" in a tag?
3) About @([\r\n])[\s]+@ :
a) no need to put \s in a char class.
b) every \r\n will be changed to \r, as \s matches \n.
I think the whole example has to be reconsidered, because there are
already functions to do some of the job, like strip_tags() and
html_entity_decode().
Previous Comments:
[2006-01-20 23:54:03] pornel at despammed dot com
Description:
The code on http://uk.php.net/preg_replace:
$search = array ('@]*?>.*?@si', // Strip
out javascript
'@<[\/\!]*?[^<>]*?>@si', // Strip
out HTML tags
doesn't work as advertised. For example it will leave
contents of:
xxx
and worse, it will output valid script tags if given:
<<>script>evil<<>/script>
If these patterns were used on some website (for stripping
markup from user's comments for example), they'd allow XSS
attack.
Since it's near impossible to properly parse HTML with
regular expressions I suggest:
* renaming example from 'Convert HTML to text' to 'Remove
HTML markup'
* adding replacement of '<' as '>'
* suggesting use of more robust methods, like strip_tags,
nl2br, htmlspecialchars or DOM interface.
--
Edit this bug report at http://bugs.php.net/?id=36112&edit=1
[PHP-DOC] #36705 [Com]: Location header results in duplicate Status header ([f]cgi only)
ID: 36705
Comment by: ali dot sencer at gmail dot com
Reported By: alisencer at gmail dot com
Status: Open
Bug Type: Documentation problem
Operating System: FreeBSD
PHP Version: 5.1.2
New Comment:
download and tried it (php5.1-200603121330)
$ ./php -v
PHP 5.1.3RC2-dev (cgi-fcgi) (built: Feb 20 2006 15:24:12)
...
[EMAIL PROTECTED]:~/php5.1-200603121330/sapi/cgi$ echo "http://www.example.org' );?>" | ./php
Status: 302
X-Powered-By: PHP/5.1.3RC2-dev
Status: 301
Location: http://www.example.org
Content-type: text/html
The bug is still present.
> One should not use "Status: 123" but "HTTP/1.x 123".
Did I miss an announcement? Since when is that? Using HTTP/1.x type
headers was not working on a variety of systems with (f)cgi, which is
why the following snippet was introduced (which is in a lot of
applications):
if (substr(php_sapi_name(), 0, 3) == 'cgi')
header("Status: $status");
else
header("HTTP/1.1 $status");
(which was the only solution that worked on all systems - until some
recent changes in newer releases.)
I could have sworn this was somehwere in the documentation even. So in
which versions was this changed? How can portable applications in PHP
be written, if these things change silently every now and then.
Why can header("Status: ") be used at all, if it's not supposed to be
used?
Can the behaviour at least be "fixed" in such a way, that (f)cgi won't
send "Status: " twice, which results in a 500 error by the webserver.
Thanks.
[edit: I am the bug-submitter, but must have mistyped my password]
Previous Comments:
[2006-03-12 15:55:22] [EMAIL PROTECTED]
Recalssifying as a documentation problem.
One should not use "Status: 123" but "HTTP/1.x 123".
[2006-03-12 15:39:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-12 14:14:36] alisencer at gmail dot com
Description:
In php-fastcgi, a header("Location: ..") call always results in an
additional "Status:" header. This causes the web server to throw a 500
Internal server error.
Identical code works perfectly in mod_php. The problem is specific to
fastcgi.
It doesn't matter what Status code the first header() call sends; the
"Location:" call always adds a second "Status: 302" line.
The effect is, that it becomes impossible to use
header("Location;..."), if at any previous point in the script a Status
header has been sent. It is also contrary to what the documentation
says:
http://de.php.net/manual/en/function.header.php
"The second special case is the "Location:" header. Not only does it
send this header back to the browser, but it also returns a REDIRECT
(302) status code to the browser unless some 3xx status code has
already been set."
(Note the last part of that paragraph)
Related: This seems to be what was happening in this bug report as
well: http://bugs.php.net/bug.php?id=33225 which unfortunately was
closed as bogus.
Reproduce code:
---
$ echo "http://www.example.org' );?>" | php/php-fastcgi/php5-fcgi
Expected result:
Content-type: text/html; charset=UTF-8
Status: 301
Location: http://www.example.com
Actual result:
--
Status: 302
Content-type: text/html; charset=UTF-8
Status: 301
Location: http://www.example.com
--
Edit this bug report at http://bugs.php.net/?id=36705&edit=1
[PHP-DOC] #36705 [Fbk->Opn]: Location header results in duplicate Status header ([f]cgi only)
ID: 36705
Updated by: [EMAIL PROTECTED]
Reported By: alisencer at gmail dot com
-Status: Feedback
+Status: Open
-Bug Type: CGI related
+Bug Type: Documentation problem
Operating System: FreeBSD
PHP Version: 5.1.2
New Comment:
Recalssifying as a documentation problem.
One should not use "Status: 123" but "HTTP/1.x 123".
Previous Comments:
[2006-03-12 15:39:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-12 14:14:36] alisencer at gmail dot com
Description:
In php-fastcgi, a header("Location: ..") call always results in an
additional "Status:" header. This causes the web server to throw a 500
Internal server error.
Identical code works perfectly in mod_php. The problem is specific to
fastcgi.
It doesn't matter what Status code the first header() call sends; the
"Location:" call always adds a second "Status: 302" line.
The effect is, that it becomes impossible to use
header("Location;..."), if at any previous point in the script a Status
header has been sent. It is also contrary to what the documentation
says:
http://de.php.net/manual/en/function.header.php
"The second special case is the "Location:" header. Not only does it
send this header back to the browser, but it also returns a REDIRECT
(302) status code to the browser unless some 3xx status code has
already been set."
(Note the last part of that paragraph)
Related: This seems to be what was happening in this bug report as
well: http://bugs.php.net/bug.php?id=33225 which unfortunately was
closed as bogus.
Reproduce code:
---
$ echo "http://www.example.org' );?>" | php/php-fastcgi/php5-fcgi
Expected result:
Content-type: text/html; charset=UTF-8
Status: 301
Location: http://www.example.com
Actual result:
--
Status: 302
Content-type: text/html; charset=UTF-8
Status: 301
Location: http://www.example.com
--
Edit this bug report at http://bugs.php.net/?id=36705&edit=1
[PHP-DOC] Notes Status, 14876 total
Following are the top 20 pages of the manual, sorted by the number of user notes contributed. These sections could use a polish, those notes represent 9.1% of the 14876 total user notes. Notes | Page ---+- 96 | http://php.net/manual/en/function.header.php 87 | http://php.net/manual/en/function.preg-replace.php 82 | http://php.net/manual/en/ref.xml.php 81 | http://php.net/manual/en/ref.session.php 73 | http://php.net/manual/en/ref.image.php 73 | http://php.net/manual/en/function.mktime.php 71 | http://php.net/manual/en/reserved.variables.php 65 | http://php.net/manual/en/function.strtotime.php 63 | http://php.net/manual/en/function.strpos.php 63 | http://php.net/manual/en/function.date.php 63 | http://php.net/manual/en/function.fsockopen.php 62 | http://php.net/manual/en/function.mssql-connect.php 62 | http://php.net/manual/en/function.readdir.php 62 | http://php.net/manual/en/features.file-upload.php 61 | http://php.net/manual/en/ref.mail.php 60 | http://php.net/manual/en/ref.com.php 60 | http://php.net/manual/en/function.str-replace.php 58 | http://php.net/manual/en/function.in-array.php 58 | http://php.net/manual/en/function.array-search.php 57 | http://php.net/manual/en/function.preg-match.php
[PHP-DOC] cvs: phpdoc /en/reference/filter reference.xml
vrana Sun Mar 12 09:19:09 2006 UTC Modified files: /phpdoc/en/reference/filter reference.xml Log: IDs are constants http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/filter/reference.xml?r1=1.2&r2=1.3&diff_format=u Index: phpdoc/en/reference/filter/reference.xml diff -u phpdoc/en/reference/filter/reference.xml:1.2 phpdoc/en/reference/filter/reference.xml:1.3 --- phpdoc/en/reference/filter/reference.xml:1.2Sun Mar 12 01:36:27 2006 +++ phpdoc/en/reference/filter/reference.xmlSun Mar 12 09:19:09 2006 @@ -1,5 +1,5 @@ - + @@ -31,8 +31,8 @@ -FILTER_VALIDATE_INT -int +FILTER_VALIDATE_INT +"int" min_range, max_range @@ -44,8 +44,8 @@ Validates value as integer, optionally from the specified range. -FILTER_VALIDATE_BOOLEAN -boolean +FILTER_VALIDATE_BOOLEAN +"boolean" @@ -55,16 +55,16 @@ -FILTER_VALIDATE_FLOAT -float +FILTER_VALIDATE_FLOAT +"float" Validates value as float. -FILTER_VALIDATE_REGEXP -validate_regexp +FILTER_VALIDATE_REGEXP +"validate_regexp" regexp @@ -72,8 +72,8 @@ Validates value against regexp. -FILTER_VALIDATE_URL -validate_url +FILTER_VALIDATE_URL +"validate_url" FILTER_FLAG_SCHEME_REQUIRED, @@ -84,15 +84,15 @@ Validates value as URL, optionally with required components. -FILTER_VALIDATE_EMAIL -validate_email +FILTER_VALIDATE_EMAIL +"validate_email" Validates value as e-mail. -FILTER_VALIDATE_IP -validate_ip +FILTER_VALIDATE_IP +"validate_ip" FILTER_FLAG_IPV4, @@ -107,8 +107,8 @@ -FILTER_SANITIZE_STRING -string +FILTER_SANITIZE_STRING +"string" FILTER_FLAG_NO_ENCODE_QUOTES, @@ -121,15 +121,15 @@ Strip tags, optionally strip or encode special characters. -FILTER_SANITIZE_STRIPPED -stripped +FILTER_SANITIZE_STRIPPED +"stripped" Alias of "string" filter. -FILTER_SANITIZE_ENCODED -encoded +FILTER_SANITIZE_ENCODED +"encoded" FILTER_FLAG_STRIP_LOW, @@ -140,8 +140,8 @@ URL-encode string, optionally strip or encode special characters. -FILTER_SANITIZE_SPECIAL_CHARS -special_chars +FILTER_SANITIZE_SPECIAL_CHARS +"special_chars" FILTER_FLAG_STRIP_LOW, @@ -155,8 +155,8 @@ -FILTER_UNSAFE_RAW -unsafe_raw +FILTER_UNSAFE_RAW +"unsafe_raw" FILTER_FLAG_STRIP_LOW, @@ -168,8 +168,8 @@ Do nothing, optionally strip or encode special characters. -FILTER_SANITIZE_EMAIL -email +FILTER_SANITIZE_EMAIL +"email" @@ -178,8 +178,8 @@ -FILTER_SANITIZE_URL -url +FILTER_SANITIZE_URL +"url" @@ -188,8 +188,8 @@ -FILTER_SANITIZE_NUMBER_INT -number_int +FILTER_SANITIZE_NUMBER_INT +"number_int" @@ -197,8 +197,8 @@ -FILTER_SANITIZE_NUMBER_FLOAT -number_float +FILTER_SANITIZE_NUMBER_FLOAT +"number_float" @@ -207,16 +207,16 @@ -FILTER_SANITIZE_MAGIC_QUOTES -magic_quotes +FILTER_SANITIZE_MAGIC_QUOTES +"magic_quotes" Apply addslashes. -FILTER_CALLBACK -callback +FILTER_CALLBACK +"callback" callback function or method Call user-defined function to filter data.
[PHP-DOC] cvs: phpdoc /en/reference/filter/functions input-get.xml
vrana Sun Mar 12 09:14:41 2006 UTC Modified files: /phpdoc/en/reference/filter/functions input-get.xml Log: Default value of filter. http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/filter/functions/input-get.xml?r1=1.1&r2=1.2&diff_format=u Index: phpdoc/en/reference/filter/functions/input-get.xml diff -u phpdoc/en/reference/filter/functions/input-get.xml:1.1 phpdoc/en/reference/filter/functions/input-get.xml:1.2 --- phpdoc/en/reference/filter/functions/input-get.xml:1.1 Sat Mar 11 21:19:27 2006 +++ phpdoc/en/reference/filter/functions/input-get.xml Sun Mar 12 09:14:41 2006 @@ -1,5 +1,5 @@ - + @@ -47,7 +47,7 @@ filter - Filter to apply. + Filter to apply. Defaults to FILTER_DEFAULT.
[PHP-DOC] cvs: phpdoc /en/reference/filter ini.xml
vrana Sun Mar 12 08:53:46 2006 UTC Modified files: /phpdoc/en/reference/filter ini.xml Log: Changeable, typo, description of filter.default http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/filter/ini.xml?r1=1.1&r2=1.2&diff_format=u Index: phpdoc/en/reference/filter/ini.xml diff -u phpdoc/en/reference/filter/ini.xml:1.1 phpdoc/en/reference/filter/ini.xml:1.2 --- phpdoc/en/reference/filter/ini.xml:1.1 Sat Mar 11 21:19:27 2006 +++ phpdoc/en/reference/filter/ini.xml Sun Mar 12 08:53:46 2006 @@ -1,5 +1,5 @@ - + &reftitle.runtime; &extension.runtime; @@ -19,13 +19,13 @@ filter.default string - PHP_INI_ALL + PHP_INI_SYSTEM - filter.default-flags + filter.default_flags - PHP_INI_ALL + PHP_INI_SYSTEM @@ -45,7 +45,8 @@ - Filter all GET, POST, COOKIE (and REQUEST) data by this filter. + Filter all $_GET, $_POST, $_COOKIE and $_REQUEST data by this filter. + Original data can be accessed through input_get.
