Bug #64345 [Opn->Nab]: Please specify correct PostgreSQL installation path
Edit report at https://bugs.php.net/bug.php?id=64345&edit=1 ID: 64345 Updated by: paj...@php.net Reported by:americancafe at hotmail dot com Summary:Please specify correct PostgreSQL installation path -Status: Open +Status: Not a bug Type: Bug Package:PostgreSQL related Operating System: OSX 10.6 PHP Version:5.4.12 Block user comment: N Private report: N New Comment: You have to know how your platform works or where it installs files if you like to compile PHP yourself. On the other side, if you don't want to bother with that, use macports or other PHP packages for OS X. If you still like to compile PHP, a simple google query will point you to many tutorials, f.e.: http://drewish.com/content/2008/12/getting_php_gd_postgresql_working_on_osx_105_ aka_recompiling_everything Previous Comments: [2013-03-04 06:51:55] americancafe at hotmail dot com Description: Now I have tried and tried. I already know what you're going to say "This is not a bug". Well it is to me and 100 other people who have posted this question onilne with no good response. >Cannot find libpq-fe.h< Well, I know exaclty where that library is. But, no one can tell me how to SPECIFY it to PHP. Test script: --- ./configure --with-pgsql=/usrThis does not work ./configure --with-pgsql=/somePath This does not work ./configure --with-pgsql='/somePath' This does not work Expected result: I expect PHP to configure. Actual result: -- configure: error: Cannot find libpq-fe.h. Please specify correct PostgreSQL installation path And how do I do that? Please stop assuming that everyone knows what you know. -- Edit this bug report at https://bugs.php.net/bug.php?id=64345&edit=1
[PHP-BUG] Bug #64345 [NEW]: Please specify correct PostgreSQL installation path
From: americancafe at hotmail dot com Operating system: OSX 10.6 PHP version: 5.4.12 Package: PostgreSQL related Bug Type: Bug Bug description:Please specify correct PostgreSQL installation path Description: Now I have tried and tried. I already know what you're going to say "This is not a bug". Well it is to me and 100 other people who have posted this question onilne with no good response. >Cannot find libpq-fe.h< Well, I know exaclty where that library is. But, no one can tell me how to SPECIFY it to PHP. Test script: --- ./configure --with-pgsql=/usrThis does not work ./configure --with-pgsql=/somePath This does not work ./configure --with-pgsql='/somePath' This does not work Expected result: I expect PHP to configure. Actual result: -- configure: error: Cannot find libpq-fe.h. Please specify correct PostgreSQL installation path And how do I do that? Please stop assuming that everyone knows what you know. -- Edit bug report at https://bugs.php.net/bug.php?id=64345&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64345&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64345&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64345&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64345&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64345&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64345&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64345&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64345&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64345&r=support Expected behavior: https://bugs.php.net/fix.php?id=64345&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64345&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64345&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64345&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64345&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64345&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64345&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64345&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64345&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64345&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64345&r=mysqlcfg
Req #64344 [Opn->Wfx]: Option to suppress illegal session id warnings
Edit report at https://bugs.php.net/bug.php?id=64344&edit=1 ID: 64344 Updated by: larue...@php.net Reported by:nick at noodles dot net dot nz Summary:Option to suppress illegal session id warnings -Status: Open +Status: Wont fix Type: Feature/Change Request Package:Session related Operating System: All PHP Version:5.4.12 Block user comment: N Private report: N New Comment: I hope you understand. we will not add that many options to disable every kind of warning message. Previous Comments: [2013-03-04 02:45:20] nick at noodles dot net dot nz @session_start would suppress all errors/warnings. There might be an instance where my session store (memcache) may not be working correctly or may be inaccessible and I wouldn't want to stop those messages. [2013-03-04 02:42:36] larue...@php.net why not @session_start [2013-03-04 01:34:58] nick at noodles dot net dot nz Description: We have a few users a day trying to inject things into their PHPSESSID cookie for some reason. When they request a page on our site with session_start() PHP generates a warning "session_start(): The session id is too long or contains illegal characters". This is a redundant message as PHP recovers and resets the PHPSESSID to a legal one. It would be great to see a session.warn_illegal_id (or similar) option to suppress these warnings. Test script: --- Set cookie PHPSESSID to 1747d33a3556d5bf141706eb271bf972,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,JSESSIONID=20AB177A036A09CB0B9D58D19589529C,ASPSESSIONIDASBCCDAQ=MNEJOAJBPCMLMPEDCMFCKGKL,JSESSIONID=UZBDOYZSUXNZCCUUCAZSFFA Request a page with session_start(); Expected result: I expect session_start() to fail quietly and regenerate the PHPSESSID to a valid value. Actual result: -- Warning: session_start(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' -- Edit this bug report at https://bugs.php.net/bug.php?id=64344&edit=1
Req #64344 [Opn]: Option to suppress illegal session id warnings
Edit report at https://bugs.php.net/bug.php?id=64344&edit=1 ID: 64344 User updated by:nick at noodles dot net dot nz Reported by:nick at noodles dot net dot nz Summary:Option to suppress illegal session id warnings Status: Open Type: Feature/Change Request Package:Session related Operating System: All PHP Version:5.4.12 Block user comment: N Private report: N New Comment: @session_start would suppress all errors/warnings. There might be an instance where my session store (memcache) may not be working correctly or may be inaccessible and I wouldn't want to stop those messages. Previous Comments: [2013-03-04 02:42:36] larue...@php.net why not @session_start [2013-03-04 01:34:58] nick at noodles dot net dot nz Description: We have a few users a day trying to inject things into their PHPSESSID cookie for some reason. When they request a page on our site with session_start() PHP generates a warning "session_start(): The session id is too long or contains illegal characters". This is a redundant message as PHP recovers and resets the PHPSESSID to a legal one. It would be great to see a session.warn_illegal_id (or similar) option to suppress these warnings. Test script: --- Set cookie PHPSESSID to 1747d33a3556d5bf141706eb271bf972,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,JSESSIONID=20AB177A036A09CB0B9D58D19589529C,ASPSESSIONIDASBCCDAQ=MNEJOAJBPCMLMPEDCMFCKGKL,JSESSIONID=UZBDOYZSUXNZCCUUCAZSFFA Request a page with session_start(); Expected result: I expect session_start() to fail quietly and regenerate the PHPSESSID to a valid value. Actual result: -- Warning: session_start(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' -- Edit this bug report at https://bugs.php.net/bug.php?id=64344&edit=1
Req #64344 [Opn]: Option to suppress illegal session id warnings
Edit report at https://bugs.php.net/bug.php?id=64344&edit=1 ID: 64344 Updated by: larue...@php.net Reported by:nick at noodles dot net dot nz Summary:Option to suppress illegal session id warnings Status: Open Type: Feature/Change Request Package:Session related Operating System: All PHP Version:5.4.12 Block user comment: N Private report: N New Comment: why not @session_start Previous Comments: [2013-03-04 01:34:58] nick at noodles dot net dot nz Description: We have a few users a day trying to inject things into their PHPSESSID cookie for some reason. When they request a page on our site with session_start() PHP generates a warning "session_start(): The session id is too long or contains illegal characters". This is a redundant message as PHP recovers and resets the PHPSESSID to a legal one. It would be great to see a session.warn_illegal_id (or similar) option to suppress these warnings. Test script: --- Set cookie PHPSESSID to 1747d33a3556d5bf141706eb271bf972,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,JSESSIONID=20AB177A036A09CB0B9D58D19589529C,ASPSESSIONIDASBCCDAQ=MNEJOAJBPCMLMPEDCMFCKGKL,JSESSIONID=UZBDOYZSUXNZCCUUCAZSFFA Request a page with session_start(); Expected result: I expect session_start() to fail quietly and regenerate the PHPSESSID to a valid value. Actual result: -- Warning: session_start(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' -- Edit this bug report at https://bugs.php.net/bug.php?id=64344&edit=1
[PHP-BUG] Req #64344 [NEW]: Option to suppress illegal session id warnings
From: nick at noodles dot net dot nz Operating system: All PHP version: 5.4.12 Package: Session related Bug Type: Feature/Change Request Bug description:Option to suppress illegal session id warnings Description: We have a few users a day trying to inject things into their PHPSESSID cookie for some reason. When they request a page on our site with session_start() PHP generates a warning "session_start(): The session id is too long or contains illegal characters". This is a redundant message as PHP recovers and resets the PHPSESSID to a legal one. It would be great to see a session.warn_illegal_id (or similar) option to suppress these warnings. Test script: --- Set cookie PHPSESSID to 1747d33a3556d5bf141706eb271bf972,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,OAID=43014df373346fd1eff98e7c7d3dcfc4,JSESSIONID=20AB177A036A09CB0B9D58D19589529C,ASPSESSIONIDASBCCDAQ=MNEJOAJBPCMLMPEDCMFCKGKL,JSESSIONID=UZBDOYZSUXNZCCUUCAZSFFA Request a page with session_start(); Expected result: I expect session_start() to fail quietly and regenerate the PHPSESSID to a valid value. Actual result: -- Warning: session_start(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' -- Edit bug report at https://bugs.php.net/bug.php?id=64344&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64344&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64344&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64344&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64344&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64344&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64344&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64344&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64344&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64344&r=support Expected behavior: https://bugs.php.net/fix.php?id=64344&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64344&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64344&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64344&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64344&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64344&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64344&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64344&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64344&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64344&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64344&r=mysqlcfg
[PHP-BUG] Bug #64343 [NEW]: PharData::extractTo fails for tarball created by BSD tar
From: njh at aelius dot com
Operating system: Mac OS 10.7.5
PHP version: 5.4.12
Package: PHAR related
Bug Type: Bug
Bug description:PharData::extractTo fails for tarball created by BSD tar
Description:
The extractTo() method in Phar doesn't seem to work with tar archives
generated
using the BSD version of the tar tool, which is the version that comes
pre-
installed on Mac OS X.
I have uploaded two sample tar files, which both contain a single test.txt
file:
http://www.aelius.com/njh/tmp/tartest/test-bsd.tar.gz
http://www.aelius.com/njh/tmp/tartest/test-gnu.tar.gz
When run the GNU generated tar file works correctly but the BSD generated
tar
file fails.
This problem came up with trying to install dependencies using composer,
that
had been generated using BSD tar on Mac OS X:
https://github.com/composer/composer/issues/1492
Test script:
---
extractTo('extracted-gnu');
$phar = new PharData('test-bsd.tar.gz');
$phar->extractTo('extracted-bsd');
Expected result:
Both the test-bsd.tar.gz and test-gnu.tar.gz should extract the test.txt
file.
Actual result:
--
Fatal error: Uncaught exception 'UnexpectedValueException' with message
'phar
error: "/tmp/tartest/test-bsd.tar.gz" is a corrupted tar file (checksum
mismatch
of file "18 uid=1451698731
20 ctime=1362335175
20 atime=1362335267
24 SCHILY.dev=234881029
23 SCHILY.ino=1224")' in /tmp/tartest/test.php:5
Stack trace:
#0 /tmp/tartest/test.php(5): PharData->__construct('test-bsd.tar.gz')
#1 {main}
thrown in /tmp/tartest/test.php on line 5
--
Edit bug report at https://bugs.php.net/bug.php?id=64343&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64343&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64343&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64343&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64343&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64343&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64343&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64343&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64343&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64343&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64343&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64343&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64343&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64343&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64343&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64343&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64343&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64343&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64343&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64343&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64343&r=mysqlcfg
[PHP-BUG] Bug #64342 [NEW]: ZipArchive::Close returns false on large file trees
From: kolan_n at mail dot ru Operating system: Windows PHP version: 5.4.12 Package: Zip Related Bug Type: Bug Bug description:ZipArchive::Close returns false on large file trees Description: If you try to archive large file trees using ZipArchive you get false at ZipArchive::close(). ZipArchive::getStatusString says about "unknown error" Test script: --- install https://github.com/KOLANICH/PHP-Backuper and dBug (or comment all "new dBug" in files, for example, with Notepad++) download any archive, containing "large" tree, for example Drupal, and unpack it write array( "FileTree"=>array( "unpackedArchivePath" ) ) ) ); $b->makeBackup(); ?> and launch you will see that it doesn't work the problem is on the https://github.com/KOLANICH/PHP-Backuper/blob/master/Backuper.php#L136 , $this->zip->close() returns false and the files would not be archivated. Expected result: $this->zip->close() returns true and the files are archivated Actual result: -- $this->zip->close() returns false and the files are not archivated -- Edit bug report at https://bugs.php.net/bug.php?id=64342&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64342&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64342&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64342&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64342&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64342&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64342&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64342&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64342&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64342&r=support Expected behavior: https://bugs.php.net/fix.php?id=64342&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64342&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64342&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64342&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64342&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64342&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64342&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64342&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64342&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64342&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64342&r=mysqlcfg
Bug #49151 [Com]: relocation must bind locally
Edit report at https://bugs.php.net/bug.php?id=49151&edit=1 ID: 49151 Comment by: eugene at zhegan dot in Reported by:tech at uscki dot nl Summary:relocation must bind locally Status: Open Type: Bug Package:Compile Failure Operating System: Sun Solaris 5.10 (i386) PHP Version:5.3.0 Block user comment: N Private report: N New Comment: Guys, this stuff about relocation errors is still actual for the php 5.4.x and gcc 4.x, for example on Solaris 10 and gcc 4.7.2 (althought it does not fire on Solaris 11 and less recent gcc). No questions, it still builds just fine using gcc 3.4.3, but any way 3.4.3 will go sooner or later. Still helps to edit the Makefile manually and remove -fvisibility=hidden. Previous Comments: [2012-03-14 06:18:52] sergei dot solomonov at gmail dot com Try this: ext/date/php_date.c:511 (line 508, for php 5.4) -zend_class_entry *date_ce_date, *date_ce_timezone, *date_ce_interval, *date_ce_period; +static zend_class_entry *date_ce_date, *date_ce_timezone, *date_ce_interval, *date_ce_period; [2010-09-13 23:45:24] brentk at birs dot ca I'm getting the same problem with PHP 5.3.3 on Solaris 10 (x64), gcc 4.3.3. The compile dies at php_date.o with the same message as the original post. If I remove the "-fvisibility=hidden" part from configure, this doesn't happen. [2010-05-24 17:20:11] dbakyle at gmail dot com I've removed the -fvisibility=hidden from the Makefile and tried the make again. The process is still failing on glob_wrapper.lo I'm using 4.1.2 of gcc and 2.6.18-92.1.22.0.1 of Red Hat. [2009-08-17 09:42:07] j...@php.net It should be as simple as adding 'static' in the macro ZEND_DECLARE_MODULE_GLOBALS since those should be static anyway.. [2009-08-14 23:13:32] tech at uscki dot nl Yeah, got it compiling! I removed "-fvisibility=hidden" from the Makefile after running ./configure, guess that boils down to the same result, though your suggestion is a bit tidier. Compiler: gcc (GCC) 4.0.1 Thanks for all your help! 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=49151 -- Edit this bug report at https://bugs.php.net/bug.php?id=49151&edit=1
Bug #64325 [Fbk]: Issue in automatic $_POST array handling
Edit report at https://bugs.php.net/bug.php?id=64325&edit=1
ID: 64325
Updated by: larue...@php.net
Reported by:php at sygmoral dot com
Summary:Issue in automatic $_POST array handling
Status: Feedback
Type: Bug
Package:*General Issues
Operating System: Debian
PHP Version:5.4.12
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
I noticed, that's why I didn't going further,
and I don't think it related to documented or not:
https://bugs.php.net/patch-display.php?bug=64325&patch=bug64325.patch&revision=1362108583
[2013-03-01 03:29:02] larue...@php.net
PHP won't allow variables name to contains "[", "." etc , so I think this is
really a narrow usage.
but, however I do believe there is a bug.
a patch will be attached. but I need to ask someone else's opinion before
commit
it.
thanks
[2013-02-28 19:45:57] php at sygmoral dot com
Thank you for your reaction!
But no: I did in fact mean what I wrote. I realise it's a strange data
structure, so here's a short explanation for it: the 'save' array holds a
collection of html form elements that are not yet to be submitted, but should
be saved temporarily into some other set of memory, so that upon the next
visit, those temporary values can be easily inserted into the displayed form,
without having been submitted. In other words, it's for a form that remembers
its state throughout visits.
So I send an object containing the name-value pairs in the form, and send that
over POST. In the example used here, this results in one or more name-value
pairs that are saved into the save array, as save['line[]'] = value.
And that is the situation that triggers this bug, as in my original post. I'm
sure there are other ways to achieve what I want, but I figured I'd report it
since this does not look as if it's intended.
Note that the example is a simplification of my application, where multiple
'single' and 'array' values are saved.
[2013-02-28 18:22:57] re...@php.net
"post_data = {'save[line[]]':'A line with text'}â
do you mean post_data = {'save[line][]':'A line with text'} ?
^^
is this you intention?
array(
'save' =>
['line' =>
['A line with text', 'maybe more lines']
]
); ?
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=64325
--
Edit this bug report at https://bugs.php.net/bug.php?id=64325&edit=1
Bug #64325 [Fbk]: Issue in automatic $_POST array handling
Edit report at https://bugs.php.net/bug.php?id=64325&edit=1
ID: 64325
Updated by: re...@php.net
Reported by:php at sygmoral dot com
Summary:Issue in automatic $_POST array handling
Status: Feedback
Type: Bug
Package:*General Issues
Operating System: Debian
PHP Version:5.4.12
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The attached patch may break form like: foo[bar][index]=test
after some research, this seems a undocumented behavior but not a bug.
only the field name `save` can not have '[' and other special chars.
the subkeys didn't required to be a legal variable name but '[]' are special
chars.
Previous Comments:
[2013-03-01 03:29:43] larue...@php.net
The following patch has been added/updated:
Patch Name: bug64325.patch
Revision: 1362108583
URL:
https://bugs.php.net/patch-display.php?bug=64325&patch=bug64325.patch&revision=1362108583
[2013-03-01 03:29:02] larue...@php.net
PHP won't allow variables name to contains "[", "." etc , so I think this is
really a narrow usage.
but, however I do believe there is a bug.
a patch will be attached. but I need to ask someone else's opinion before
commit
it.
thanks
[2013-02-28 19:45:57] php at sygmoral dot com
Thank you for your reaction!
But no: I did in fact mean what I wrote. I realise it's a strange data
structure, so here's a short explanation for it: the 'save' array holds a
collection of html form elements that are not yet to be submitted, but should
be saved temporarily into some other set of memory, so that upon the next
visit, those temporary values can be easily inserted into the displayed form,
without having been submitted. In other words, it's for a form that remembers
its state throughout visits.
So I send an object containing the name-value pairs in the form, and send that
over POST. In the example used here, this results in one or more name-value
pairs that are saved into the save array, as save['line[]'] = value.
And that is the situation that triggers this bug, as in my original post. I'm
sure there are other ways to achieve what I want, but I figured I'd report it
since this does not look as if it's intended.
Note that the example is a simplification of my application, where multiple
'single' and 'array' values are saved.
[2013-02-28 18:22:57] re...@php.net
"post_data = {'save[line[]]':'A line with text'}â
do you mean post_data = {'save[line][]':'A line with text'} ?
^^
is this you intention?
array(
'save' =>
['line' =>
['A line with text', 'maybe more lines']
]
); ?
[2013-02-28 16:09:49] php at sygmoral dot com
Description:
Php automatically puts POSTed name-value pairs with names ending in [] into
arrays. Very handy feature! However, I notice issues when more of those square
brackets are encountered.
If I send a name like `save[line[]]`, then `save` will be an array and the
first key in it will be `line[`, instead of `line[]`. It's not that I expect a
second level of arrays - just that it doesn't strangely remove that last
bracket.
So suppose we have the tiny php script below, and I send this with e.g. jquery:
post_data = {'save[line[]]':'A line with text'}
Effectively, the raw POST data being sent is:
save%5Bline%5B%5D%5D=A+line+with+text
Test script:
---
print_r(
$_POST['save']
);
Expected result:
POST: Array
(
[line[]] => A line with text
)
Actual result:
--
POST: Array
(
[line[] => A line with text
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64325&edit=1
