#47042 [Opn]: php cgi sapi is incorrectly removing the SCRIPT_FILENAME for non apache
ID: 47042
User updated by: sriram dot natarajan at sun dot com
Reported By: sriram dot natarajan at sun dot com
Status: Open
Bug Type: CGI related
Operating System: linux , solaris
PHP Version: 5.2.9
New Comment:
i have tested this patch with apache 2.0 and 2.2 configurations within
cgi and was able to get applications like joomla working fine.
can some one kindly look into the attached patch and provide your
feedback
thanks
Previous Comments:
[2009-02-28 09:18:55] sriram dot natarajan at sun dot com
Hi
php cgi module assumes that if redirect_uri is set , the request must
be from apache and throws away the script_name value and assigns
path_translated value to script name.
this is because, in cgi environment, apache sets the SCRIPT_NAME to
the location of the php-cgi binary and keeping the PATH_INFO variable to
point to the requested php script. this is very unique only to apache.
this crude test condition for apache is affecting sun web server
executing in fastcgi mode where in it looses the script_name value and
ends up returning with 'no input file specified'.
this happens only for sun web server and not for lighttpd because
lighttpd does not set redirect_uri when requested for index.php.
based on this analysis , earlier, i provided a patch to address this
issue . however, i overlooked the obvious and ended up breaking apache
in cgi mode.
because of this, a separate bug : http://bugs.php.net/bug.php?id=47149
has been filed and my suggested patch was reverted.
my sincere apology on providing this obviously broken patch and wasting
some of your time.
pl. find attached a below patch that should do the right thing.
what we want to do is
a) compare whether the script path is different from path translated
since we know that apache by default sets the script name to point to
the location of cgi binary and not the requested uri
[sn123...@samp]'php5'>diff -u php-5.2.9/sapi/cgi/cgi_main.c.ORIG
php-5.2.9/sapi/cgi/cgi_main.c
--- php-5.2.9/sapi/cgi/cgi_main.c.ORIG Sat Feb 28 00:44:54 2009
+++ php-5.2.9/sapi/cgi/cgi_main.c Sat Feb 28 00:46:00 2009
@@ -961,7 +961,8 @@
}
if (env_path_translated != NULL &&
env_redirect_url != NULL &&
- orig_script_filename != NULL &&
script_path_translated != NULL) {
+ env_path_translated !=
script_path_translated &&
+ strcmp(env_path_translated,
script_path_translated) != 0) {
/*
pretty much apache specific. If we
have a redirect_url
then our script_filename and
script_name point to the
[2009-01-11 11:13:02] d...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2009-01-08 22:19:12] sriram dot natarajan at sun dot com
previous patch had whitespaces instead of tabs causing the patch to
appear distorted.
posting a same patch with this issue addressed
--- sapi/cgi/cgi_main.c.ORIGThu Jan 8 14:18:25 2009
+++ sapi/cgi/cgi_main.c Thu Jan 8 14:18:31 2009
@@ -960,7 +960,9 @@
TRANSLATE_SLASHES(env_document_root);
}
- if (env_path_translated != NULL &&
env_redirect_url != NULL) {
+ if (env_path_translated != NULL &&
env_redirect_url != NULL &&
+ orig_script_filename != NULL &&
script_path_translated != NULL &&
+ strcmp(orig_script_filename,
script_path_translated) != 0) {
/*
pretty much apache specific. If we
have a redirect_url
then our script_filename and
script_name point to the
[2009-01-08 20:06:25] sriram dot natarajan at sun dot com
here is the suggested patch to address this issue
--- sapi/cgi/cgi_main.c.ORIGWed Jan 7 07:10:14 2009
+++ sapi/cgi/cgi_main.c Wed Jan 7 19:37:21 2009
@@ -960,16 +960,18 @@
TRANSLATE_SLASHES(env_document_root);
}
- if (env_path_translated != NULL &&
env_redirect_url != NULL) {
- /*
- pretty much apache specific. If we
have a redirect_url
- then our script_filename and
script_name point to t
#47550 [NEW]: mysql_real_escape_strings_set()
From: alexander at vourtsis dot com Operating system: Windows Linux OSX PHP version: 5.3.0beta1 PHP Bug Type: *Database Functions Bug description: mysql_real_escape_strings_set() Description: I'd want to suggest a function to switch escaping of input strings for an sql query. So far escaping occurs by the use of mysql_real_escape_string(). Using this for each variable can result into a clutter like, mysql_real_escape_string($test1); mysql_real_escape_string($test2); mysql_real_escape_string($test3); mysql_real_escape_string($test4); I suggest to create a function to turn real escape string on and off like, mysql_real_escape_strings_set(1); and to get if escaping is on: mysql_real_escape_strings_get(); Thank you in Advance, Reproduce code: --- --- >From manual page: function.mysql-real-escape-string --- -- Edit bug report at http://bugs.php.net/?id=47550&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47550&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47550&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47550&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47550&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47550&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47550&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47550&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47550&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47550&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47550&r=support Expected behavior: http://bugs.php.net/fix.php?id=47550&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47550&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47550&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47550&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47550&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47550&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47550&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47550&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47550&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47550&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47550&r=mysqlcfg
#47539 [Opn]: MySQL module slow close
ID: 47539 User updated by: ian at ianhobson dot co dot uk Reported By: ian at ianhobson dot co dot uk Status: Open Bug Type: MySQL related Operating System: win32 only -Win2K PHP Version: 5.2.9 New Comment: It looks as if this bug has been around since 5.2.2 See bugs 41968 and 41350. Previous Comments: [2009-03-02 10:46:33] ian at ianhobson dot co dot uk I am fairly sure it is. I recall renaming the MySQL version (libmySQL.dll.save is still in the MySQL directory), and copy/pasting the php version in. All three copies of that file on my machine... a) Do not have any version information in the properties box. b) Are sized exactly 2076672 bytes. c) Are dated when I installed php and mySQl (except one which is dated the date I unpacked php5.2.9) The pathnames are D:\wamp\bin\php\php5.2.8 php 5.2.8 D:\wamp\bin\mysql\mysql5.1.30\binMySQl 5.1.30 D:\test php 5.2.9 libmySQL.dll.save is sized at 2,260,992 bytes [2009-03-02 09:26:54] johan...@php.net Which libmysql.dll is being used? The one which is part of the PHP distribution? [2009-03-01 21:55:16] ian at ianhobson dot co dot uk Description: If php_mysql.dll or php_mysqli.dll are enabled, the CLI takes 5 seconds to close. Reproduce code: --- @echo off time phpx The current time is: 21:50:50.39 Enter the new time: HiThe current time is: 21:50:55.44 Enter the new time: D:\Websites\ppg\testsop\tests> The times differ by over 5 seconds. Windows, AMD 3500+, with 3GB RAM and fast hard disk. -- Edit this bug report at http://bugs.php.net/?id=47539&edit=1
#40479 [Com]: zend_mm_heap corrupted
ID: 40479 Comment by: hakan dot koseoglu at gmail dot com Reported By: rrossi at maggioli dot it Status: No Feedback Bug Type: Reproducible crash Operating System: Suse Linux 9.0 PHP Version: 5.2.1 New Comment: The same problem appears from a allegedly successful compilation op PHP 5.2.9 on RHEL5 64 bit using -m32 CFLAG so that the binaries are 32 bit. The compilation appears to complete successfully: Apache 2.0.59 compiled w/o any problems with the following configure and it works fine. ./configure --prefix=/apps/apache2 --with-expat=builtin PHP is configured with the following options: ./configure --with-apxs2=/apps/apache2/bin/apxs --build=i386-redhat-linux --with-pic --with-gd --with-zlib --with-config-file-path=/apps/apache2/conf --with-libdir=/lib/ --enable-debug And after the successful run, make test was run with the following errors: [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-tests.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x08c71270 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:144, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0xD03365E6) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cdd80 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cdb78 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cd9ac status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' /apps/source/php-5.2.9/main/streams/plain_wrapper.c(160) : Freeing 0x097CD9AC (108 bytes), script=/apps/source/php-5.2.9/run-test-info .php /apps/source/php-5.2.9/ext/standard/php_fopen_wrapper.c(312) : Actual location (location was relayed) Last leak repeated 2 times === Total 3 memory leaks detected === [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-tests.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x08c734c4 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:292, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0xD03365E6) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '-' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x086d7038 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x4C780131) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '-' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x086d6e30 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x4C780131) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '-' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x086d6c64 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x4C780131) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009]
#47546 [Opn->Csd]: Default value for limit parameter in explode is 0, not -1
ID: 47546 Updated by: ka...@php.net Reported By: jordi dot salvat at localbilinglimited dot com -Status: Open +Status: Closed -Bug Type: Documentation problem +Bug Type: Strings related Operating System: Irrelevant -PHP Version: Irrelevant +PHP Version: 5.2.9 -Assigned To: +Assigned To: kalle New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Fixed in PHP 5.2.10 Previous Comments: [2009-03-02 17:25:26] jordi dot salvat at localbilinglimited dot com Description: http://es.php.net/explode declares that the default value for the 3rd parameter of the explode function is -1. The function, however, behaves differently when -1 is passed explicitly. Reproduce code: --- php <<'__END__' __END__ Expected result: >From the documentation, I would expect to see the same result twice. Actual result: -- Array ( [0] => one [1] => two [2] => three [3] => four ) Array ( [0] => one [1] => two [2] => three ) -- Edit this bug report at http://bugs.php.net/?id=47546&edit=1
#47520 [Bgs]: PHP segfaulted in preg_replace on processing long string
ID: 47520
User updated by: pahan at hubbitus dot spb dot su
Reported By: pahan at hubbitus dot spb dot su
Status: Bogus
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.3.0beta1
New Comment:
Problem in pcre library is a problem of pcre library.
BUT segmentation fault of PHP is a bug PHP itself in any case!!!
I can understand what it may be very hard to fix, but completely do not
understand why you mark it as Bogus!
Previous Comments:
[2009-03-03 01:40:03] il...@php.net
There is not much we can do about recursion limits other then suggest
the lowering of the pcre.recursion_limit setting. The basic problem is
that PCRE library (not PHP) is eating up the system stack during
recursion and subsequently crashes when it runs out of room.
This is not a PHP bug.
[2009-03-02 10:09:28] phpwnd at gmail dot com
I forgot to add that in my case, lowering the value the
pcre.recursion_limit INI setting make preg_* functions fail instead of
making PHP segfault.
[2009-03-02 10:01:52] phpwnd at gmail dot com
I'd like to add that you don't need such a complicated test case, you
can make preg_* segfault with just something like:
$str = str_repeat(' ', 2490);
preg_match('#(.)+#', $str);
On my computer, a 2490-chars string is long enough to make it segfaults
everytime. For some reason, 2489 chars will make it segfault only 1 out
of 5 runs and 2480 chars are perfectly fine. If I replace the regexp
with more capturing parenthesis such as #((.))+# that limit drops to
1500-or-so and that number decreases as the number of parenthesis
increases. Using non-capturing patterns such as #(?:.)+# doubles that
number.
Obviously, the bug is related to capturing patterns repetition,
assuming we're experiencing the same bug. I'll try to find a place where
to host a core dump.
[2009-02-28 09:00:02] pahan at hubbitus dot spb dot su
Very apologize for mistake.
I'm fix rights now, please recheck.
[2009-02-28 01:19:21] fel...@php.net
I cannot download the coredump file: "You don't have permission to
access /_temp/php-pcre-bug/2/core.10135 on this server."
Can you give us a backtrace?
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/47520
--
Edit this bug report at http://bugs.php.net/?id=47520&edit=1
#44589 [Com]: pdo_oci crashes and aborts php script for LOB columns
ID: 44589 Comment by: simong at bluhalo dot com Reported By: s dot rost at ewerk dot com Status: Assigned Bug Type: PDO related Operating System: Debian 2.6.18.dfsg.1-18etch1 PHP Version: 5.2.5 Assigned To: cjorcl New Comment: We are receiving the same segfault in PHP 5.2.8 This is our backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208256752 (LWP 8743)] 0x0324e96f in kghufree () from /usr/lib/oracle/10.2.0.4/client/lib/libclntsh.so.10.1 (gdb) bt #0 0x0324e96f in kghufree () from /usr/lib/oracle/10.2.0.4/client/lib/libclntsh.so.10.1 #1 0x031eea1f in kohfrem () from /usr/lib/oracle/10.2.0.4/client/lib/libclntsh.so.10.1 #2 0x031ee29c in kohfrr () from /usr/lib/oracle/10.2.0.4/client/lib/libclntsh.so.10.1 #3 0x031eeca7 in kohfrw () from /usr/lib/oracle/10.2.0.4/client/lib/libclntsh.so.10.1 #4 0x0308a438 in kollfrfn () from /usr/lib/oracle/10.2.0.4/client/lib/libclntsh.so.10.1 #5 0x02b369f9 in kpufdesc () from /usr/lib/oracle/10.2.0.4/client/lib/libclntsh.so.10.1 #6 0x02c079be in OCIDescriptorFree () from /usr/lib/oracle/10.2.0.4/client/lib/libclntsh.so.10.1 #7 0x011e129c in oci_blob_close (stream=0xa11026c, close_handle=1) at /root/php-5.2.8/ext/pdo_oci/oci_statement.c:652 #8 0x013626b1 in _php_stream_free (stream=0xa11026c, close_options=56830048) at /root/php-5.2.8/main/streams/streams.c:350 #9 0x013628db in stream_resource_regular_dtor (rsrc=0xa1102f0) at /root/php-5.2.8/main/streams/streams.c:1371 #10 0x0139bc22 in list_entry_destructor (ptr=0xa1102f0) at /root/php-5.2.8/Zend/zend_list.c:184 #11 0x0139a16d in zend_hash_del_key_or_index (ht=0x151f720, arKey=0xa12cd , nKeyLength=0, h=173, flag=1) at /root/php-5.2.8/Zend/zend_hash.c:497 #12 0x0139be6c in _zend_list_delete (id=173) at /root/php-5.2.8/Zend/zend_list.c:58 #13 0x0138321f in _zval_ptr_dtor (zval_ptr=0xa110a58) at /root/php-5.2.8/Zend/zend_variables.h:35 #14 0x013993e6 in zend_hash_destroy (ht=0xa110b94) at /root/php-5.2.8/Zend/zend_hash.c:526 #15 0x0138f2c5 in _zval_dtor_func (zvalue=0xa1107bc) at /root/php-5.2.8/Zend/zend_variables.c:43 #16 0x0138321f in _zval_ptr_dtor (zval_ptr=0xa10f97c) at /root/php-5.2.8/Zend/zend_variables.h:35 #17 0x013993e6 in zend_hash_destroy (ht=0xa11051c) at /root/php-5.2.8/Zend/zend_hash.c:526 #18 0x013a7f73 in zend_object_std_dtor (object=0xa1104f0) at /root/php-5.2.8/Zend/zend_objects.c:45 #19 0x013a7fa2 in zend_objects_free_object_storage (object=0xa1104f0) at /root/php-5.2.8/Zend/zend_objects.c:122 #20 0x013ab2a9 in zend_objects_store_del_ref_by_handle (handle=156) at /root/php-5.2.8/Zend/zend_objects_API.c:206 #21 0x013ab2e8 in zend_objects_store_del_ref (zobject=0xa110504) at /root/php-5.2.8/Zend/zend_objects_API.c:168 #22 0x0138321f in _zval_ptr_dtor (zval_ptr=0xa110cec) at /root/php-5.2.8/Zend/zend_variables.h:35 #23 0x013993e6 in zend_hash_destroy (ht=0xa10fb88) at /root/php-5.2.8/Zend/zend_hash.c:526 #24 0x0138f2c5 in _zval_dtor_func (zvalue=0xa10fd88) at /root/php-5.2.8/Zend/zend_variables.c:43 #25 0x0138321f in _zval_ptr_dtor (zval_ptr=0x9f22dd0) at /root/php-5.2.8/Zend/zend_variables.h:35 #26 0x013993e6 in zend_hash_destroy (ht=0x9ee9718) at /root/php-5.2.8/Zend/zend_hash.c:526 #27 0x013a7f73 in zend_object_std_dtor (object=0x9f1832c) at /root/php-5.2.8/Zend/zend_objects.c:45 #28 0x013a7fa2 in zend_objects_free_object_storage (object=0x9f1832c) at /root/php-5.2.8/Zend/zend_objects.c:122 #29 0x013ab2a9 in zend_objects_store_del_ref_by_handle (handle=118) at /root/php-5.2.8/Zend/zend_objects_API.c:206 #30 0x013ab2e8 in zend_objects_store_del_ref (zobject=0x9f22c58) at /root/php-5.2.8/Zend/zend_objects_API.c:168 #31 0x0138321f in _zval_ptr_dtor (zval_ptr=0x9e3bab4) at /root/php-5.2.8/Zend/zend_variables.h:35 #32 0x013993e6 in zend_hash_destroy (ht=0x9e3b958) at /root/php-5.2.8/Zend/zend_hash.c:526 #33 0x013a7f73 in zend_object_std_dtor (object=0x9dcf218) at /root/php-5.2.8/Zend/zend_objects.c:45 #34 0x013a7fa2 in zend_objects_free_object_storage (object=0x9dcf218) at /root/php-5.2.8/Zend/zend_objects.c:122 #35 0x013aaecd in zend_objects_store_free_object_storage (objects=0x151f7c8) at /root/php-5.2.8/Zend/zend_objects_API.c:89 #36 0x01383a21 in shutdown_executor () at /root/php-5.2.8/Zend/zend_execute_API.c:299 #37 0x0138f833 in zend_deactivate () at /root/php-5.2.8/Zend/zend.c:860 #38 0x0134f6d7 in php_request_shutdown (dummy=0x0) at /root/php-5.2.8/main/main.c:1492 #39 0x01409946 in php_handler (r=0x99ba468) at /root/php-5.2.8/sapi/apache2handler/sapi_apache2.c:469 #40 0x0029c96d in ap_run_handler () from /usr/sbin/httpd #41 0x002a0318 in ap_invoke_handler () from /usr/sbin/httpd #42 0x002ac38e in ap_process_request () from /usr/sbin/httpd #43 0x002a916f in ap_register_input_filter () from /usr/sbin/httpd #44 0x002a483d in ap_run_process_connection () from /usr/sbin/httpd #45 0x002a493c in ap_process_connection () from /usr/sbin/httpd #46 0x002b0952 in ap_graceful_stop_signalled () from /usr/sb
#47551 [NEW]: Export zend_ini_scanner_get_lineno
From: dpatterson at dplhenterprises dot com Operating system: Windows PHP version: 5.3.0beta1 PHP Bug Type: Feature/Change Request Bug description: Export zend_ini_scanner_get_lineno Description: It is not currently possible for an extension that calls zend_ini_scanner_get_lineno() to be built shared under Windows. This is because the zend_ini_scanner_get_lineno() symbol is not exported via the ZEND_API macro. Please modify zend_ini_scanner.h and zend_ini_scanner.c, adding ZEND_API to the prototype and definition of the zend_ini_scanner_get_lineno() function. Thank you. -- Edit bug report at http://bugs.php.net/?id=47551&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47551&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47551&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47551&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47551&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47551&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47551&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47551&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47551&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47551&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47551&r=support Expected behavior: http://bugs.php.net/fix.php?id=47551&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47551&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47551&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47551&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47551&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47551&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47551&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47551&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47551&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47551&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47551&r=mysqlcfg
#47553 [NEW]: Problem with multi-dimensional $_FILES
From: david at olyeo dot co dot uk Operating system: Ubuntu 8.04 PHP version: 5.2CVS-2009-03-03 (snap) PHP Bug Type: Streams related Bug description: Problem with multi-dimensional $_FILES Description: Hi, I am just working with multi-dimensional file uploads and they are not coming out as expected, i.e. they are not coming out the same as a single file upload. I don't see why this should be - why not just output all file upload in the same way? Reproduce code: --- I am using a form that has these fields: I am deliberately using multiple-depths as I am building an automatic form handler that will be able to handle any form. Expected result: 'submission' => array ( 'screenshot' => array 'name' => 'monster_wallpaper.jpg' 'type' => 'image/jpeg' 'tmp_name' => '/tmp/php48lX2Y' 'error' => 0 'size' => 223262 ), 'other' => array ( 'dem' => array ( '0' => array ( 'img' => array ( '0' => 'mood_wallpaper.png' 'type' => 'image/png' 'tmp_name' => '/tmp/phpLotX1Q' 'error' => 0 'size' => 27809 ), ), ), ) Actual result: -- array( 'submission' => array ( 'name' => array ( 'screenshot' => 'monster_wallpaper.jpg' ), 'type' => array ( 'screenshot' => 'image/jpeg' ), 'tmp_name' => array ( 'screenshot' => '/tmp/php48lX2Y' ), 'error' => array ( 'screenshot' => 0 ), 'size' => array ( 'screenshot' => 223262 ), ), 'other' => array ( 'name' => array ( 'dem' => array ( '0' => array ( 'img' => array ( '0' => 'mood_wallpaper.png' ), ), ), ), 'type' => array ( 'dem' => array ( '0' => array ( 'img' => array ( '0' => 'image/png' ), ), ), ), 'tmp_name' => array ( 'dem' => array ( '0' => array ( 'img' => array ( '0' => '/tmp/phpLotX1Q' ), ), ), ), 'error' => array ( 'dem' => array ( '0' => array ( 'img' => array ( '0' => 0 ), ), ), ), 'size' => array ( 'dem' => array ( '0' => array ( 'img' => array ( '0' => 27809 ), ), ), ), ), ); -- Edit bug report at http://bugs.php.net/?id=47553&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47553&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47553&r=trysnapshot53 Try a CVS snapshot (PHP 6.0):
#47473 [Fbk->Opn]: set_error_handler() crashes the
ID: 47473 User updated by: typo3 at maltejansen dot de Reported By: typo3 at maltejansen dot de -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows Vista PHP Version: 5.3.0beta1 New Comment: The max path length is just an example, which is treated differently on the OS. I have tried to setup fastcgi in my xampp installation. But I always get in 500 error. I tried the nearly every thing from google, but every where there seems to be missing something. Do you have a complete example of including fastcgi in the apache-conf for windows? On Max und Linux is working. So this is realy just a windows bug. Previous Comments: [2009-02-25 14:45:05] paj...@php.net I don't see why the max path lenght limit (which can affect other systems as well) is related to this backtrace. Can you try it using a threaded SAPI under linux or using fastcgi on windows please? [2009-02-25 10:21:26] typo3 at maltejansen dot de No, on Linux it's running smoothly (with SAPI I don't know, but it should), because otherwise Robert or Karsten (Project-Leader) would already be in contact, what there a with other bugs. It's just on windows, they using mac/linux. It seems to be something like the length of a filename on windows with just 260 characters. The first time the crash occured, switching from alpha1 to alpha2. In alpha3 it seems to be solved, because we thought it was connected to this bug [1] and it was not crashing anymore. In beta1 it was there again. [1] http://bugs.php.net/bug.php?id=46241 [2009-02-25 10:06:18] paj...@php.net Do you mean that you can't reproduce this bug on Linux/Unix (and thread safe SAPI)? We still a self contained script to reproduce the problem. [2009-02-25 10:00:33] typo3 at maltejansen dot de It's just a problem on Windows Vista (and properbly on Windows XP): So I have made the backtrace of the apache. The just using the php.exe does not work right now. (There is somewhere a bug in the CLI-version of the FLOW3-controller) So this one will follow, tomorrow. But for now: PHP-Version: Wed Feb 25 09:04:13 2009 apache__PID__4956__Date__02_25_2009__Time_10_26_11AM__627__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name ~...~ Operating System Windows Vista Service Pack 1 Number Of Processors 2 Process ID 4956 Process Image ~\workspaces\flow3\xampplite\apache\bin\apache.exe System Up-Time 1 day(s) 01:42:07 Process Up-Time 00:06:50 Thread 240 - System ID 5404 Entry point msvcr71!endthreadex+31 Create time 25.02.2009 10:19:23 Time spent in user mode 0 Days 0:0:2.59 Time spent in kernel mode 0 Days 0:0:8.954 Function Arg 1 Arg 2 Arg 3 Source php5ts!zend_hash_apply+37 08702778 01aa0070 03d68fc0 php5ts!zval_mark_grey+8c 08707b78 03d68fc0 769c9d32 php5ts!gc_mark_roots+95 03d68fc0 769c9d32 0792fa54 php5ts!gc_collect_cycles+64 03d68fc0 03d68fc0 0013 php5ts!zend_deactivate+12d PHP5TS!ZEND_HASH_APPLY+37In apache__PID__4956__Date__02_25_2009__Time_10_26_11AM__627__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!zend_hash_apply+37 in ~\workspaces\flow3\xampplite\apache\bin\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x000d on thread 240 This is my first time with bug-backtrace. So, tell me, if there is something else to adjust, except from the manual. I have include php like this in the apache: LoadModule php5_module "~/workspaces/flow3/xampplite/apache/bin/php5apache2_2.dll" [2009-02-24 10:48:10] j...@php.net You can always try generating a backtrace of that crash yourself, instructions are here: http://bugs.php.net/bugs-generating-backtrace win32.php It's propably easier to accomplish with better tools like valgrind on any *nix system. Unless of course this happens only within win32 env. 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/47473 -- Edit this bug report at http://bugs.php.net/?id=47473&edit=1
#47178 [Opn->Sus]: Missing gzip headers in gzencode() output
ID: 47178 Updated by: m...@php.net Reported By: wharmby at uk dot ibm dot com -Status: Open +Status: Suspended Bug Type: Zlib Related Operating System: Windows XP PHP Version: 6CVS-2009-01-21 (snap) Assigned To: mike New Comment: Hi Andy! Sorry for the standard-bla of the quick fix in my previos response. Interestingly, gzencode(..., FORCE_DEFLATE) does not make any sense to me in PHP versions lower than v6. I cannot remember why or even if I noticed this legacy behaviour back when I reimplemented zlib code. For clarification: RFC1951 = raw deflate - not much to say here RFC1950 = zlib encoding, AKA HTTP deflate; - being [zlib header][deflated data][adler checksum] RFC1952 = gzip encoding - being [gzip header][deflated data][crc32 checksum, original size] The output of PHP5s gzencode(..., FORCE_DEFLATE) is neither of the previous formats, but rather zlib encoded data additionally prepended with a gzip header: [gzip header][zlib header][deflated data][adler checksum] This is obscure IMHO. Obviously, this exists and is even documented for ages, so I kindly ask you to take this issue to internals@ for discussion, so people can decide what's going to happen. Thank you. Previous Comments: [2009-03-02 11:01:28] whar...@php.net Hi Mike If you think the bug lies in php5 can you re-assign to that release please. I will fix the PHPT accordingly Regards Andy [2009-03-02 10:50:14] wharmby at uk dot ibm dot com Hi Mike Can you expand on your reason for closing this defect as bogus a little more please given that: (1) The same test produces different results on php 5.2 and 5.3, i.e the output from gzencode() with FORCE_DEFLATE includes the zlib headers in both cases. (2) The PHP manual says for the gzencode() option 'encoding mode' "If you use FORCE_DEFLATE, you get a standard zlib deflated string (inclusive zlib headers) after the gzip file header but without the trailing crc32 checksum. " This suggests that the output should include zlib headers. So if the PHP 6 behaviour is correct does this not mean there is a bug in both PHP 5 code and description of the command in the PHP manual ? I raised the bug against PHP 6 as its behaviour differed to previous releases and I assumed it was a bug in the new zlib code but if the bug lies in PHP % I am happy to fix up the new PHPT's and open a defect against PHP 5. Regards Andy Andy Wharmby E-mail: andy_whar...@uk.ibm.com [2009-02-28 14:01:33] m...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Of course raw deflate encoded data does not have a gzip header. [2009-01-21 11:41:35] wharmby at uk dot ibm dot com New tests dropped for gzencode dropped to php 5.2, 5.3 and 6. ext/zlib/tests/gzencode_variation2 ext/zlib/tests/gzencode_variation2-win32 in PHP 6 both tagged with XFAIL sections referencing this defect [2009-01-21 10:27:36] wharmby at uk dot ibm dot com Description: Missing gzip headers in output from gzencode() when FORCE_DEFLATE option specified. Problem persists for all values for $level argument. Problem seen at PHP 6 level only. I will be dropping some new PHPT shortly; the PHP 6 version will be tagged with XFAIL section because of this defect. Reproduce code: --- Expected result: Based on output for same script from 5.2/5.3 I expect something like: unicode(62) "1f8b0803f348cdc9c95708cf2fca49010056b1174a0b00" unicode(58) "1f8b0803789cf348cdc9c95708cf2fca490100180b041d" Actual result: -- unicode(62) "1f8b080bf348cdc9c95708cf2fca49010056b1174a0b00" unicode(38) "789cf348cdc9c95708cf2fca490100180b041d" -- Edit this bug report at http://bugs.php.net/?id=47178&edit=1
#47551 [Opn]: Export zend_ini_scanner_get_lineno
ID: 47551 User updated by: dpatterson at dplhenterprises dot com Reported By: dpatterson at dplhenterprises dot com Status: Open Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.3.0beta1 New Comment: By the way, since 5.3 hasn't been released yet, it would be great if this was changed in 5.2 as well. Previous Comments: [2009-03-03 16:11:09] dpatterson at dplhenterprises dot com Description: It is not currently possible for an extension that calls zend_ini_scanner_get_lineno() to be built shared under Windows. This is because the zend_ini_scanner_get_lineno() symbol is not exported via the ZEND_API macro. Please modify zend_ini_scanner.h and zend_ini_scanner.c, adding ZEND_API to the prototype and definition of the zend_ini_scanner_get_lineno() function. Thank you. -- Edit this bug report at http://bugs.php.net/?id=47551&edit=1
#47549 [Opn->Csd]: get_defined_constants() return array with broken array categories
ID: 47549 Updated by: il...@php.net Reported By: pahan at hubbitus dot info -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.3.0beta1 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-03-03 07:49:37] pahan at hubbitus dot info Description: When $categorize parameter set to true, and expected categorized result by extension it has crazy mishmash of keys and values. Expected results got on version 5.2.9 Reproduce code: --- Expected result: Array ( [CONNECTION_ABORTED] => 1 [CONNECTION_NORMAL] => 0 [CONNECTION_TIMEOUT] => 2 [DNS_ANY] => 268435456 [DNS_ALL] => 251713587 ) Actual result: -- Array ( [PREG_PATTERN_ORDER] => 1 [PREG_SET_ORDER] => 2 [PREG_OFFSET_CAPTURE] => 256 [PREG_SPLIT_NO_EMPTY] => 1 [PREG_SPLIT_DELIM_CAPTURE] => 2 [PREG_SPLIT_OFFSET_CAPTURE] => 4 [PREG_GREP_INVERT] => 1 [PREG_NO_ERROR] => 0 [PREG_INTERNAL_ERROR] => 1 [PREG_BACKTRACK_LIMIT_ERROR] => 2 [PREG_RECURSION_LIMIT_ERROR] => 3 [PREG_BAD_UTF8_ERROR] => 4 [PREG_BAD_UTF8_OFFSET_ERROR] => 5 [PCRE_VERSION] => 7.3 2007-08-28 ) -- Edit this bug report at http://bugs.php.net/?id=47549&edit=1
#47554 [NEW]: call_user_func_array returns NULL (instead of FALSE) for invalid callbacks
From: jimmy at basicmatrix dot com Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Scripting Engine problem Bug description: call_user_func_array returns NULL (instead of FALSE) for invalid callbacks Description: call_user_func_array() claims it "Returns the function result, or FALSE on error." My testing shows it returns NULL if the callback function is not a valid callback. Reproduce code: --- Expected result: string(5) "Good." Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'not_callable' was given in ___ on line 9 FALSE Actual result: -- string(5) "Good." Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'not_callable' was given in ___ on line 9 NULL -- Edit bug report at http://bugs.php.net/?id=47554&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47554&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47554&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47554&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47554&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47554&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47554&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47554&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47554&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47554&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47554&r=support Expected behavior: http://bugs.php.net/fix.php?id=47554&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47554&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47554&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47554&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47554&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47554&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47554&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47554&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47554&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47554&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47554&r=mysqlcfg
#39130 [Com]: Compile failure when using VC++ 2005
ID: 39130 Comment by: jmckenna at gatewaygeomatics dot com Reported By: ben dot yan at msn dot com Status: No Feedback Bug Type: Compile Failure Operating System: Windows PHP Version: 5.2CVS-2007-07-22 Assigned To: pajoye New Comment: I have the exact same problem with PHP 5.2.9 and VS 2008. -jeff Previous Comments: [2008-05-20 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-05-12 09:54:03] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-02-12 03:54:48] someone at farpost dot com Fixed this error adding symbol _USE_32BIT_TIME_T to all projects in the Preprocessor Definitions. [2008-02-12 02:30:31] someone at farpost dot com Version 5.2.5 and VS 2005. Still have this problem. [2007-07-22 15:38:01] j...@php.net Wez, can you please check this out, it should be simple fix (for someone who actually has this VC++ thingie) 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/39130 -- Edit this bug report at http://bugs.php.net/?id=39130&edit=1
#39130 [NoF->WFx]: Compile failure when using VC++ 2005
ID: 39130 Updated by: paj...@php.net Reported By: ben dot yan at msn dot com -Status: No Feedback +Status: Wont fix Bug Type: Compile Failure Operating System: Windows PHP Version: 5.2CVS-2007-07-22 Assigned To: pajoye New Comment: We support VC6 only for 5.2.x, it may work with VS2008 (vc9) but there is no guarantee. PHP 5.3 supports 2008 out of the box. Previous Comments: [2009-03-03 23:58:11] jmckenna at gatewaygeomatics dot com I have the exact same problem with PHP 5.2.9 and VS 2008. -jeff [2008-05-20 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-05-12 09:54:03] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-02-12 03:54:48] someone at farpost dot com Fixed this error adding symbol _USE_32BIT_TIME_T to all projects in the Preprocessor Definitions. [2008-02-12 02:30:31] someone at farpost dot com Version 5.2.5 and VS 2005. Still have this problem. 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/39130 -- Edit this bug report at http://bugs.php.net/?id=39130&edit=1
#47555 [NEW]: Can not make PDO_OCI.so
From: geniushome at qq dot com Operating system: AIX6.1 PHP version: 5.2.9 PHP Bug Type: PDO related Bug description: Can not make PDO_OCI.so Description: Software:AIX6.1+IBM Http Server-1.3(Apache-1.3)+PHP-5.2.6 # pwd /usr/local/PDO_OCI-1.0 # /usr/local/php/bin/phpize PHP Api Version: 20041225 Zend Module Api No: 20060613 Zend Extension Api No: 220060519 # ./configure \ --with-php-config=/usr/local/php/bin/php-config \ --with-pdo-oci=instantclient,/oracle/product/10.2.0,10.2.0.3> .. .. .. checking whether to build shared libraries... no checking whether to build static libraries... yes creating libtool appending configuration tag "CXX" to libtool configure: creating ./config.status config.status: creating config.h # make .. .. creating ./pdo_oci.la (cd ./.libs && rm -f pdo_oci.la && ln -s ../pdo_oci.la pdo_oci.la) mv: 0653-401 Cannot rename ./.libs/pdo_oci.so to ./pdo_oci.so: A file or directory in the path name does not exist. make: 1254-004 The error code from the last command is 1. -- Edit bug report at http://bugs.php.net/?id=47555&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47555&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47555&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47555&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47555&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47555&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47555&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47555&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47555&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47555&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47555&r=support Expected behavior: http://bugs.php.net/fix.php?id=47555&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47555&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47555&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47555&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47555&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47555&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47555&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47555&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47555&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47555&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47555&r=mysqlcfg
#33500 [Com]: imap_open() fails when the server advertises GSSAPI
ID: 33500
Comment by: sami dot sipponen at storaenso dot com
Reported By: ed2019 at columbia dot edu
Status: Open
Bug Type: Feature/Change Request
Operating System: RHEL4
PHP Version: 4.3.10
New Comment:
Please PHP developers, fix this bug since there are no other elegant
methods to connect Exchange 2007 than imap_open. Implement
authentication method attribute to IMAP_OPEN or make it automatically
use multiple methods.
Previous Comments:
[2009-02-06 01:49:31] steve dot englart at gmail dot com
I can't connect to Exchange 2007 sp1
PHP running on Windows 2000
C:\php>php -v
PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23)
with Pear Net_POP3 1.3.6 stable
example from getMessage() after logon...
Error in authentication: USER NOT supported authentication
method!. This server supports these methods: GSSAPI, but I support APO
P,PLAIN,LOGIN,USER
[2009-01-07 20:07:47] spryde at aas dot com
Bug still present, 5.2.8, Centos 5.2.
[2008-12-07 03:59:17] phalenor at gmail dot com
imap_open() absolutely needs a way to specify the order of
authentication mechanisms to try. If one is attempting to do
username/password auth to an imap server that supports GSSAPI,
imap_open() tries GSSAPI then stops, never attempting to do PLAIN auth
or otherwise.
This should not be viewed as a misconfiguration of the imap server, as
clients that use c-client manage to try multiple auth mechs.
[2008-10-10 13:36:24] php at eikel dot org
Hello,
this problem still exists in PHP 5.2.6. As stated by Mark Crispin [1]
this problem is probably a bug in the PHP IMAP implementation. Any
suggestions how to fix this problem?
Regards,
Benjamin
[1]
http://mailman2.u.washington.edu/pipermail/imap-uw/2005-June/000101.html
[2008-06-20 15:04:41] josh_barth at hotmail dot com
If you happen to run across this error while attempting to connect to
an Exchange server... In my case Exchange 2007 from Ubuntu
Install Kerberos client i.e heimdal-client
Switch to the apache userfor Ubuntu that is "www-data":
su www-data
kinit usern...@domainname.com 'Mind the case lo...@upper
klist 'Will show current ticket granting ticket and other tokens
Note: krbtgt will expire and this procedure will need to be repeated I
am currently researching a method to ensure an active krbtgt at all
times
Try testing with this script as the apache user, replacing ipaddress,
username, domainname and password.
Connection Failure!");
echo "Mailboxes\n";
$folders = imap_listmailbox($mbox, "{ipaddress:993}", "*");
if ($folders == false) {
echo "Call failed\n";
} else {
foreach ($folders as $val) {
echo $val . "\n";
}
}
echo "Headers in INBOX\n";
$headers = imap_headers($mbox);
if ($headers == false) {
echo "Call failed\n";
} else {
foreach ($headers as $val) {
echo $val . "\n";
}
}
imap_close($mbox);
?>
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/33500
--
Edit this bug report at http://bugs.php.net/?id=33500&edit=1
