Req #60760 [Com]: Converting zend_parse_parameters() to zend_parse_parameters_none()
Edit report at https://bugs.php.net/bug.php?id=60760&edit=1 ID: 60760 Comment by: dragoo...@php.net Reported by:dragoo...@php.net Summary:Converting zend_parse_parameters() to zend_parse_parameters_none() Status: Open Type: Feature/Change Request Package:SPL related Operating System: N/A PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: This is just the way a lot of the phpsrc has been built. Look around various /ext/ places and you'll see it. I'm just cleaning things up and keeping consistency. Got a few more cleanup patches to submit on the SplHeap class for this same reason as i've been working on that class recently. - Paul. Previous Comments: [2012-01-20 02:23:52] larue...@php.net if no parameters will be accpected, why call to zend_parse_parameters? just a arginfo will be enough. [2012-01-15 03:33:27] dragoo...@php.net The following patch has been added/updated: Patch Name: spl_dllist_zend_parse_parameters_none.diff Revision: 1326598407 URL: https://bugs.php.net/patch-display.php?bug=60760&patch=spl_dllist_zend_parse_parameters_none.diff&revision=1326598407 [2012-01-15 03:32:21] dragoo...@php.net Description: Half of the file base uses zend_parse_parameters() to check if theres no params passed. Half of the file already uses zend_parse_parameters_none(). The work done here just updates zend_parse_parameters() calls to zend_parse_parameters_none() where necessary. Test script: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at https://bugs.php.net/bug.php?id=60760&edit=1
Req #60759 [PATCH]: SplDoublyLinkedList->clear()
Edit report at https://bugs.php.net/bug.php?id=60759&edit=1 ID: 60759 Patch added by: dragoo...@php.net Reported by:dragoo...@php.net Summary:SplDoublyLinkedList->clear() Status: Open Type: Feature/Change Request Package:SPL related Operating System: N/A PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: spl_dllist_clear Revision: 1326667071 URL: https://bugs.php.net/patch-display.php?bug=60759&patch=spl_dllist_clear&revision=1326667071 Previous Comments: [2012-01-15 22:37:16] dragoo...@php.net I think it's much more appropriate to rename this to clear() as it implies wiping contents of something. The original idea of reset() wasn't a good one as the term 'reset' in PHP usually refers to resetting an internal pointer of a list. New patch attached as spl_dllist_clear. ---- [2012-01-15 22:29:54] dragoo...@php.net Renaming the reset() method to clear() ---- [2012-01-15 03:26:24] dragoo...@php.net Description: The patch adds a reset() method to the SplDoublyLinkedList class. This allows the internal list to be wiped cleaned for reuse. Test script: --- push(5); var_dump($d->count()); $d->reset(); var_dump($d->count()); int(1) int(0) Actual result: -- push(5); var_dump($d->count()); $d->reset(); var_dump($d->count()); int(1) int(0) -- Edit this bug report at https://bugs.php.net/bug.php?id=60759&edit=1
Req #60759 [Com]: SplDoublyLinkedList->clear()
Edit report at https://bugs.php.net/bug.php?id=60759&edit=1 ID: 60759 Comment by: dragoo...@php.net Reported by:dragoo...@php.net Summary:SplDoublyLinkedList->clear() Status: Open Type: Feature/Change Request Package:SPL related Operating System: N/A PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: I think it's much more appropriate to rename this to clear() as it implies wiping contents of something. The original idea of reset() wasn't a good one as the term 'reset' in PHP usually refers to resetting an internal pointer of a list. New patch attached as spl_dllist_clear. Previous Comments: [2012-01-15 22:29:54] dragoo...@php.net Renaming the reset() method to clear() [2012-01-15 03:26:24] dragoo...@php.net Description: The patch adds a reset() method to the SplDoublyLinkedList class. This allows the internal list to be wiped cleaned for reuse. Test script: --- push(5); var_dump($d->count()); $d->reset(); var_dump($d->count()); int(1) int(0) Actual result: -- push(5); var_dump($d->count()); $d->reset(); var_dump($d->count()); int(1) int(0) -- Edit this bug report at https://bugs.php.net/bug.php?id=60759&edit=1
Req #60760 [PATCH]: Converting zend_parse_parameters() to zend_parse_parameters_none()
Edit report at https://bugs.php.net/bug.php?id=60760&edit=1 ID: 60760 Patch added by: dragoo...@php.net Reported by:dragoo...@php.net Summary:Converting zend_parse_parameters() to zend_parse_parameters_none() Status: Open Type: Feature/Change Request Package:SPL related Operating System: N/A PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: spl_dllist_zend_parse_parameters_none.diff Revision: 1326598407 URL: https://bugs.php.net/patch-display.php?bug=60760&patch=spl_dllist_zend_parse_parameters_none.diff&revision=1326598407 Previous Comments: [2012-01-15 03:32:21] dragoo...@php.net Description: Half of the file base uses zend_parse_parameters() to check if theres no params passed. Half of the file already uses zend_parse_parameters_none(). The work done here just updates zend_parse_parameters() calls to zend_parse_parameters_none() where necessary. Test script: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at https://bugs.php.net/bug.php?id=60760&edit=1
[PHP-BUG] Req #60760 [NEW]: Converting zend_parse_parameters() to zend_parse_parameters_none()
From: dragoonis Operating system: N/A PHP version: 5.4.0RC5 Package: SPL related Bug Type: Feature/Change Request Bug description:Converting zend_parse_parameters() to zend_parse_parameters_none() Description: Half of the file base uses zend_parse_parameters() to check if theres no params passed. Half of the file already uses zend_parse_parameters_none(). The work done here just updates zend_parse_parameters() calls to zend_parse_parameters_none() where necessary. Test script: --- N/A Expected result: N/A Actual result: -- N/A -- Edit bug report at https://bugs.php.net/bug.php?id=60760&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60760&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60760&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60760&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60760&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60760&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60760&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60760&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60760&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60760&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60760&r=support Expected behavior: https://bugs.php.net/fix.php?id=60760&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60760&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60760&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60760&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60760&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60760&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60760&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60760&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60760&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60760&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60760&r=mysqlcfg
[PHP-BUG] Req #60759 [NEW]: SplDoublyLinkedList->reset()
From: dragoonis Operating system: N/A PHP version: 5.4.0RC5 Package: SPL related Bug Type: Feature/Change Request Bug description:SplDoublyLinkedList->reset() Description: The patch adds a reset() method to the SplDoublyLinkedList class. This allows the internal list to be wiped cleaned for reuse. Test script: --- push(5); var_dump($d->count()); $d->reset(); var_dump($d->count()); int(1) int(0) Actual result: -- push(5); var_dump($d->count()); $d->reset(); var_dump($d->count()); int(1) int(0) -- Edit bug report at https://bugs.php.net/bug.php?id=60759&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60759&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60759&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60759&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60759&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60759&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60759&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60759&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60759&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60759&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60759&r=support Expected behavior: https://bugs.php.net/fix.php?id=60759&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60759&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60759&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60759&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60759&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60759&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60759&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60759&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60759&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60759&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60759&r=mysqlcfg
Bug #60683 [Com]: Interactive Mode doesn't reach prompt
Edit report at https://bugs.php.net/bug.php?id=60683&edit=1 ID: 60683 Comment by: dragoo...@php.net Reported by:da...@php.net Summary:Interactive Mode doesn't reach prompt Status: Open Type: Bug Package:CGI/CLI related Operating System: OSX 10.7.2 & Ubuntu 11.04 PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: @rk, If there's support required for another library then it shouldn't let you enter interactive mode, and back out, giving you a useful error message to tell you there are missing dependencies.. Previous Comments: [2012-01-13 21:45:44] rk at srsbiz dot pl IMHO it's not a bug, to have interactive shell you have to configure with readline support, not just clean './configure' ---- [2012-01-08 05:37:10] dragoo...@php.net I confirmed this case with davey on Mac OSX Lion Darwin Paul-Dragooniss-MacBook-Pro.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64 05:10 macosx lion.. My build details are: -- bash-3.2$ ../build/bin/php -v PHP 5.4.0RC6-dev (cli) (built: Jan 8 2012 03:03:04) (DEBUG) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies Thanks. [2012-01-08 05:31:44] da...@php.net Description: * Using OS X Lion 10.7.2 or Ubuntu 11.04 (Natty), and basic "./configure". If you run php -a, you never reach the prompt, and nothing entered will work. All you can do is ^C to kill it. Setting cli.prompt does not help. Test script: --- $ php -a Expected result: $ php -a Interactive mode enabled php > Actual result: -- $ php -a Interactive mode enabled (wait. wait. wait.) ^C Backtrace if helpful: #0 0x7fff87f6ad52 in read$NOCANCEL () #1 0x7fff86883c25 in _sread () #2 0x7fff86884166 in __srefill1 () #3 0x7fff86884cb2 in __fread () #4 0x7fff86884b34 in fread () #5 0x00010028744c in zend_stream_getc [inlined] () at /Users/davey/src/php- 5.4.0RC5/Zend/zend_stream.c:148 #6 0x00010028744c in zend_stream_read (file_handle=0x0, buf=0x1009356a0 "? V?", len=4096) at zend_stream.c:168 #7 0x0001002878fb in zend_stream_fixup (file_handle=0x0, buf=0x7fff5fbfecc0, len=0x7fff5fbfecb8) at zend_stream.c:262 #8 0x0001002493be in open_file_for_scanning (file_handle=0x7fff5fbff958) at zend_language_scanner.l:483 #9 0x00010024a190 in compile_file (file_handle=0x7fff5fbff958, type=8) at zend_language_scanner.l:566 #10 0x000100159ba2 in phar_compile_file (file_handle=0x0, type=1606414144) at phar.c:3391 #11 0x000100272b57 in zend_execute_scripts (type=8, retval=0x7fff5fbff0a0, file_count=1606414496) at zend.c:1264 #12 0x0001002170e2 in php_execute_script (primary_file=0x7fff5fbff958) at main.c:2476 #13 0x0001002ff3e5 in do_cli [inlined] () at /Users/davey/src/php- 5.4.0RC5/sapi/cli/php_cli.c:983 #14 0x0001002ff3e5 in main (argc=1606417184, argv=0x0) at php_cli.c:1356 -- Edit this bug report at https://bugs.php.net/bug.php?id=60683&edit=1
Bug #60683 [Com]: Interactive Mode doesn't reach prompt
Edit report at https://bugs.php.net/bug.php?id=60683&edit=1 ID: 60683 Comment by: dragoo...@php.net Reported by:da...@php.net Summary:Interactive Mode doesn't reach prompt Status: Open Type: Bug Package:CGI/CLI related Operating System: OSX 10.7.2 & Ubuntu 11.04 PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: I confirmed this case with davey on Mac OSX Lion Darwin Paul-Dragooniss-MacBook-Pro.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64 05:10 macosx lion.. My build details are: -- bash-3.2$ ../build/bin/php -v PHP 5.4.0RC6-dev (cli) (built: Jan 8 2012 03:03:04) (DEBUG) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies Thanks. Previous Comments: [2012-01-08 05:31:44] da...@php.net Description: * Using OS X Lion 10.7.2 or Ubuntu 11.04 (Natty), and basic "./configure". If you run php -a, you never reach the prompt, and nothing entered will work. All you can do is ^C to kill it. Setting cli.prompt does not help. Test script: --- $ php -a Expected result: $ php -a Interactive mode enabled php > Actual result: -- $ php -a Interactive mode enabled (wait. wait. wait.) ^C Backtrace if helpful: #0 0x7fff87f6ad52 in read$NOCANCEL () #1 0x7fff86883c25 in _sread () #2 0x7fff86884166 in __srefill1 () #3 0x7fff86884cb2 in __fread () #4 0x7fff86884b34 in fread () #5 0x00010028744c in zend_stream_getc [inlined] () at /Users/davey/src/php- 5.4.0RC5/Zend/zend_stream.c:148 #6 0x00010028744c in zend_stream_read (file_handle=0x0, buf=0x1009356a0 "? V?", len=4096) at zend_stream.c:168 #7 0x0001002878fb in zend_stream_fixup (file_handle=0x0, buf=0x7fff5fbfecc0, len=0x7fff5fbfecb8) at zend_stream.c:262 #8 0x0001002493be in open_file_for_scanning (file_handle=0x7fff5fbff958) at zend_language_scanner.l:483 #9 0x00010024a190 in compile_file (file_handle=0x7fff5fbff958, type=8) at zend_language_scanner.l:566 #10 0x000100159ba2 in phar_compile_file (file_handle=0x0, type=1606414144) at phar.c:3391 #11 0x000100272b57 in zend_execute_scripts (type=8, retval=0x7fff5fbff0a0, file_count=1606414496) at zend.c:1264 #12 0x0001002170e2 in php_execute_script (primary_file=0x7fff5fbff958) at main.c:2476 #13 0x0001002ff3e5 in do_cli [inlined] () at /Users/davey/src/php- 5.4.0RC5/sapi/cli/php_cli.c:983 #14 0x0001002ff3e5 in main (argc=1606417184, argv=0x0) at php_cli.c:1356 -- Edit this bug report at https://bugs.php.net/bug.php?id=60683&edit=1
Req #52593 [Com]: Getting scope variables of the caller function
Edit report at http://bugs.php.net/bug.php?id=52593&edit=1
ID: 52593
Comment by: dragoo...@php.net
Reported by:hpolthof at gmail dot com
Summary:Getting scope variables of the caller function
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.2.14
Block user comment: N
New Comment:
Please elaborate on "such a function does not exist" with an exact error
message.
Previous Comments:
[2010-08-12 14:45:51] hpolthof at gmail dot com
Description:
In bug #48290 was the function get_caller_vars() suggested. But in that
case it was irrelevant. However do I seek such a function.
get_defined_vars() returns the vars in the current scope. As do i like
to get the variables of the caller routine.
This would allow me to use parameters from a subroutine without having
to refactor another parameter being get_defined_vars() as this would
obviously uglify my code, which would impeach the reason to refactor in
the first place.
Test script:
---
function a() {
$test = 'A';
b();
}
function b() {
$test = 'B';
$vars_local = get_defined_vars();
$vars_caller = get_caller_vars();
echo $vars_caller['test']; // Expexted: A
echo $vars_local['test']; // Expected: B
}
a();
Expected result:
A
B
Actual result:
--
such a function does not exist
--
Edit this bug report at http://bugs.php.net/bug.php?id=52593&edit=1
Req #52555 [PATCH]: Headers_List not returning HTTP Status Code
Edit report at http://bugs.php.net/bug.php?id=52555&edit=1 ID: 52555 Patch added by: dragoo...@php.net Reported by:dragoo...@php.net Summary:Headers_List not returning HTTP Status Code Status: Assigned Type: Feature/Change Request Package:*Web Server problem PHP Version:5.3.3 Assigned To:dragoonis Block user comment: N New Comment: The following patch has been added/updated: Patch Name: http_response_code Revision: 1281307771 URL: http://bugs.php.net/patch-display.php?bug=52555&patch=http_response_code&revision=1281307771 Previous Comments: [2010-08-09 00:48:57] dragoo...@php.net The following patch has been added/updated: Patch Name: httpd_response_code Revision: 1281307736 URL: http://bugs.php.net/patch-display.php?bug=52555&patch=httpd_response_code&revision=1281307736 [2010-08-07 15:54:44] dragoo...@php.net After some discussions in IRC we have concluded that it's best to make a new function to give us the current response code rather than modifying existing functionality. I've added the patch below to be tested and committed into TRUNK or wherever. Cheers. Paul. ---- [2010-08-07 15:53:20] dragoo...@php.net The following patch has been added/updated: Patch Name: http_response_code Revision: 1281189200 URL: http://bugs.php.net/patch-display.php?bug=52555&patch=http_response_code&revision=1281189200 ---- [2010-08-06 14:15:06] dragoo...@php.net As per IRC conversations, the status_line or http_response_code are not headers therefore should not be returned from headers_list() so the conclusion is to make a new function to give you http_response_code. I will update this ticket with the patch. [2010-08-06 13:42:58] johan...@php.net RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) makes a difference between the Status-Line (6.1) and the Headers (6.2) that we allow setting the Status-Line via header() is kind of a hack, headers_list() should only list headers so users can work with them easily (like splitting up at ": " etc.) 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/bug.php?id=52555 -- Edit this bug report at http://bugs.php.net/bug.php?id=52555&edit=1
Req #52555 [PATCH]: Headers_List not returning HTTP Status Code
Edit report at http://bugs.php.net/bug.php?id=52555&edit=1
ID: 52555
Patch added by: dragoo...@php.net
Reported by:dragoo...@php.net
Summary:Headers_List not returning HTTP Status Code
Status: Assigned
Type: Feature/Change Request
Package:*Web Server problem
PHP Version:5.3.3
Assigned To:dragoonis
Block user comment: N
New Comment:
The following patch has been added/updated:
Patch Name: httpd_response_code
Revision: 1281307736
URL:
http://bugs.php.net/patch-display.php?bug=52555&patch=httpd_response_code&revision=1281307736
Previous Comments:
[2010-08-07 15:54:44] dragoo...@php.net
After some discussions in IRC we have concluded that it's best to make a
new function to give us the current response code rather than modifying
existing functionality.
I've added the patch below to be tested and committed into TRUNK or
wherever.
Cheers.
Paul.
[2010-08-07 15:53:20] dragoo...@php.net
The following patch has been added/updated:
Patch Name: http_response_code
Revision: 1281189200
URL:
http://bugs.php.net/patch-display.php?bug=52555&patch=http_response_code&revision=1281189200
----
[2010-08-06 14:15:06] dragoo...@php.net
As per IRC conversations, the status_line or http_response_code are not
headers therefore should not be returned from headers_list() so the
conclusion is to make a new function to give you http_response_code. I
will update this ticket with the patch.
[2010-08-06 13:42:58] johan...@php.net
RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) makes a difference
between the Status-Line (6.1) and the Headers (6.2) that we allow
setting the Status-Line via header() is kind of a hack, headers_list()
should only list headers so users can work with them easily (like
splitting up at ": " etc.)
--------
[2010-08-06 12:50:43] dragoo...@php.net
Description:
Ok so i've found the reason why this doesn't work but i'd like feedback
on the appropriate area to change as this looks like it was
intentionally developed this way.
headers_list() gets passed SG(sapi_headers).headers and prints them.
This works however when you do header() -> sapi_header_op() and you set
a response code such as 'HTTP/1.0 404 Not Found'.
It does not put this header into SG(sapi_headers).headers but it puts it
into SG(sapi_headers).http_response_code instead.
This looks to be intentional as there are special functions for updating
the response code such as sapi_update_response_code()
So the end question is, should I modify sapi_header_op() to also include
the response code in SG(sapi_headers).headers or should I modify
headers_list() to receive SG(sapi_headers).headers and
SG(sapi_headers).http_response_code.
I could also make a new function which only returns
SG(sapi_headers).http_response_code but i think that's a waste of time
and could update headers_list() or whatnot.
FYI: I tested apache_response_headers() and got no http response code in
their either.
Test script:
---
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
[2]=>
string(22) "HTTP/1.0 404 Not Found"
}
Actual result:
--
array(2) {
[0]=>
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52555&edit=1
Bug #52555 [Com]: Headers_List not returning HTTP Status Code
Edit report at http://bugs.php.net/bug.php?id=52555&edit=1
ID: 52555
Comment by: dragoo...@php.net
Reported by:dragoo...@php.net
Summary:Headers_List not returning HTTP Status Code
Status: Bogus
Type: Bug
Package:*Web Server problem
PHP Version:5.3.3
Assigned To:dragoonis
Block user comment: N
New Comment:
After some discussions in IRC we have concluded that it's best to make a
new function to give us the current response code rather than modifying
existing functionality.
I've added the patch below to be tested and committed into TRUNK or
wherever.
Cheers.
Paul.
Previous Comments:
[2010-08-07 15:53:20] dragoo...@php.net
The following patch has been added/updated:
Patch Name: http_response_code
Revision: 1281189200
URL:
http://bugs.php.net/patch-display.php?bug=52555&patch=http_response_code&revision=1281189200
[2010-08-06 14:15:06] dragoo...@php.net
As per IRC conversations, the status_line or http_response_code are not
headers therefore should not be returned from headers_list() so the
conclusion is to make a new function to give you http_response_code. I
will update this ticket with the patch.
[2010-08-06 13:42:58] johan...@php.net
RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) makes a difference
between the Status-Line (6.1) and the Headers (6.2) that we allow
setting the Status-Line via header() is kind of a hack, headers_list()
should only list headers so users can work with them easily (like
splitting up at ": " etc.)
--------
[2010-08-06 12:50:43] dragoo...@php.net
Description:
Ok so i've found the reason why this doesn't work but i'd like feedback
on the appropriate area to change as this looks like it was
intentionally developed this way.
headers_list() gets passed SG(sapi_headers).headers and prints them.
This works however when you do header() -> sapi_header_op() and you set
a response code such as 'HTTP/1.0 404 Not Found'.
It does not put this header into SG(sapi_headers).headers but it puts it
into SG(sapi_headers).http_response_code instead.
This looks to be intentional as there are special functions for updating
the response code such as sapi_update_response_code()
So the end question is, should I modify sapi_header_op() to also include
the response code in SG(sapi_headers).headers or should I modify
headers_list() to receive SG(sapi_headers).headers and
SG(sapi_headers).http_response_code.
I could also make a new function which only returns
SG(sapi_headers).http_response_code but i think that's a waste of time
and could update headers_list() or whatnot.
FYI: I tested apache_response_headers() and got no http response code in
their either.
Test script:
---
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
[2]=>
string(22) "HTTP/1.0 404 Not Found"
}
Actual result:
--
array(2) {
[0]=>
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52555&edit=1
Bug #52555 [PATCH]: Headers_List not returning HTTP Status Code
Edit report at http://bugs.php.net/bug.php?id=52555&edit=1
ID: 52555
Patch added by: dragoo...@php.net
Reported by:dragoo...@php.net
Summary:Headers_List not returning HTTP Status Code
Status: Bogus
Type: Bug
Package:*Web Server problem
PHP Version:5.3.3
Assigned To:dragoonis
Block user comment: N
New Comment:
The following patch has been added/updated:
Patch Name: http_response_code
Revision: 1281189200
URL:
http://bugs.php.net/patch-display.php?bug=52555&patch=http_response_code&revision=1281189200
Previous Comments:
[2010-08-06 14:15:06] dragoo...@php.net
As per IRC conversations, the status_line or http_response_code are not
headers therefore should not be returned from headers_list() so the
conclusion is to make a new function to give you http_response_code. I
will update this ticket with the patch.
[2010-08-06 13:42:58] johan...@php.net
RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) makes a difference
between the Status-Line (6.1) and the Headers (6.2) that we allow
setting the Status-Line via header() is kind of a hack, headers_list()
should only list headers so users can work with them easily (like
splitting up at ": " etc.)
[2010-08-06 12:50:43] dragoo...@php.net
Description:
Ok so i've found the reason why this doesn't work but i'd like feedback
on the appropriate area to change as this looks like it was
intentionally developed this way.
headers_list() gets passed SG(sapi_headers).headers and prints them.
This works however when you do header() -> sapi_header_op() and you set
a response code such as 'HTTP/1.0 404 Not Found'.
It does not put this header into SG(sapi_headers).headers but it puts it
into SG(sapi_headers).http_response_code instead.
This looks to be intentional as there are special functions for updating
the response code such as sapi_update_response_code()
So the end question is, should I modify sapi_header_op() to also include
the response code in SG(sapi_headers).headers or should I modify
headers_list() to receive SG(sapi_headers).headers and
SG(sapi_headers).http_response_code.
I could also make a new function which only returns
SG(sapi_headers).http_response_code but i think that's a waste of time
and could update headers_list() or whatnot.
FYI: I tested apache_response_headers() and got no http response code in
their either.
Test script:
---
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
[2]=>
string(22) "HTTP/1.0 404 Not Found"
}
Actual result:
--
array(2) {
[0]=>
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52555&edit=1
Bug #52555 [Com]: Headers_List not returning HTTP Status Code
Edit report at http://bugs.php.net/bug.php?id=52555&edit=1
ID: 52555
Comment by: dragoo...@php.net
Reported by:dragoo...@php.net
Summary:Headers_List not returning HTTP Status Code
Status: Bogus
Type: Bug
Package:*Web Server problem
PHP Version:5.3.3
Assigned To:dragoonis
Block user comment: N
New Comment:
As per IRC conversations, the status_line or http_response_code are not
headers therefore should not be returned from headers_list() so the
conclusion is to make a new function to give you http_response_code. I
will update this ticket with the patch.
Previous Comments:
[2010-08-06 13:42:58] johan...@php.net
RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) makes a difference
between the Status-Line (6.1) and the Headers (6.2) that we allow
setting the Status-Line via header() is kind of a hack, headers_list()
should only list headers so users can work with them easily (like
splitting up at ": " etc.)
[2010-08-06 12:50:43] dragoo...@php.net
Description:
Ok so i've found the reason why this doesn't work but i'd like feedback
on the appropriate area to change as this looks like it was
intentionally developed this way.
headers_list() gets passed SG(sapi_headers).headers and prints them.
This works however when you do header() -> sapi_header_op() and you set
a response code such as 'HTTP/1.0 404 Not Found'.
It does not put this header into SG(sapi_headers).headers but it puts it
into SG(sapi_headers).http_response_code instead.
This looks to be intentional as there are special functions for updating
the response code such as sapi_update_response_code()
So the end question is, should I modify sapi_header_op() to also include
the response code in SG(sapi_headers).headers or should I modify
headers_list() to receive SG(sapi_headers).headers and
SG(sapi_headers).http_response_code.
I could also make a new function which only returns
SG(sapi_headers).http_response_code but i think that's a waste of time
and could update headers_list() or whatnot.
FYI: I tested apache_response_headers() and got no http response code in
their either.
Test script:
---
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
[2]=>
string(22) "HTTP/1.0 404 Not Found"
}
Actual result:
--
array(2) {
[0]=>
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52555&edit=1
[PHP-BUG] Bug #52555 [NEW]: Headers_List not returning HTTP Status Code
From: dragoonis
Operating system:
PHP version: 5.3.3
Package: *Web Server problem
Bug Type: Bug
Bug description:Headers_List not returning HTTP Status Code
Description:
Ok so i've found the reason why this doesn't work but i'd like feedback on
the appropriate area to change as this looks like it was intentionally
developed this way.
headers_list() gets passed SG(sapi_headers).headers and prints them.
This works however when you do header() -> sapi_header_op() and you set a
response code such as 'HTTP/1.0 404 Not Found'.
It does not put this header into SG(sapi_headers).headers but it puts it
into SG(sapi_headers).http_response_code instead.
This looks to be intentional as there are special functions for updating
the response code such as sapi_update_response_code()
So the end question is, should I modify sapi_header_op() to also include
the response code in SG(sapi_headers).headers or should I modify
headers_list() to receive SG(sapi_headers).headers and
SG(sapi_headers).http_response_code.
I could also make a new function which only returns
SG(sapi_headers).http_response_code but i think that's a waste of time and
could update headers_list() or whatnot.
FYI: I tested apache_response_headers() and got no http response code in
their either.
Test script:
---
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
[2]=>
string(22) "HTTP/1.0 404 Not Found"
}
Actual result:
--
array(2) {
[0]=>
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
}
--
Edit bug report at http://bugs.php.net/bug.php?id=52555&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52555&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52555&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52555&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52555&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52555&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52555&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52555&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52555&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52555&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52555&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52555&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52555&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52555&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52555&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52555&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52555&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52555&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52555&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52555&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52555&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52555&r=mysqlcfg
