Req #52052 [PATCH]: add syslog support to FPM

2010-06-13 Thread f...@php.net
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1

 ID:   52052
 Patch added by:   f...@php.net
 Reported by:  ef-lists at email dot de
 Summary:  add syslog support to FPM
 Status:   Assigned
 Type: Feature/Change Request
 Package:  FPM related
 Operating System: Linux/*NIX
 PHP Version:  5.3SVN-2010-06-11 (SVN)
 Assigned To:  fat

 New Comment:

The following patch has been added/updated:

Patch Name: fpm-syslog.v2.patch
Revision:   1276418186
URL:   
http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186


Previous Comments:

[2010-06-12 19:54:05] ef-lists at email dot de

Great job! :-)



I'll try it out and report feedback to you.


[2010-06-12 18:49:35] f...@php.net

The attached patch should activate syslog sypport to error_log only. You
can try 

it on trunk.



change error_log to "syslog"



You can also set

syslog_facility and syslog_ident to feet your needs. But default values
should 

be OK.



I'm working on the slowlog patch also but it's a bit more complicated.

++ Jerome


[2010-06-12 18:47:15] f...@php.net

The following patch has been added/updated:

Patch Name: fpm-syslog.v1.patch
Revision:   1276361235
URL:   
http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235


[2010-06-11 18:10:10] ef-lists at email dot de

Description:

At current, FPM only allows logging to local files, both for the
ErrorLog and SlowLog.



Using syslog aids the administrator greatly in centralizing logfiles.

Also PHP itself has syslog support, so FPM should consequently have it,
too.



I hereby ask to add syslog support to FPM.







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1


Req #52052 [Com]: add syslog support to FPM

2010-06-13 Thread f...@php.net
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1

 ID:   52052
 Comment by:   f...@php.net
 Reported by:  ef-lists at email dot de
 Summary:  add syslog support to FPM
 Status:   Assigned
 Type: Feature/Change Request
 Package:  FPM related
 Operating System: Linux/*NIX
 PHP Version:  5.3SVN-2010-06-11 (SVN)
 Assigned To:  fat

 New Comment:

You can try instead the new revision of the patch I've just attached.



It adds sending slowlog to syslog.



Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same
values as 

log_level. By default it's LOG_DEBUG. There is no way to change the
ident and the 

facility for slowlog, it takes the same values as the globals ones 

(syslog_facility and syslog_event). There is no need to because the pool
name is 

prepended to every slowlog message.


Previous Comments:

[2010-06-13 10:36:27] f...@php.net

The following patch has been added/updated:

Patch Name: fpm-syslog.v2.patch
Revision:   1276418186
URL:   
http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186


[2010-06-12 19:54:05] ef-lists at email dot de

Great job! :-)



I'll try it out and report feedback to you.


[2010-06-12 18:49:35] f...@php.net

The attached patch should activate syslog sypport to error_log only. You
can try 

it on trunk.



change error_log to "syslog"



You can also set

syslog_facility and syslog_ident to feet your needs. But default values
should 

be OK.



I'm working on the slowlog patch also but it's a bit more complicated.

++ Jerome


[2010-06-12 18:47:15] f...@php.net

The following patch has been added/updated:

Patch Name: fpm-syslog.v1.patch
Revision:   1276361235
URL:   
http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235


[2010-06-11 18:10:10] ef-lists at email dot de

Description:

At current, FPM only allows logging to local files, both for the
ErrorLog and SlowLog.



Using syslog aids the administrator greatly in centralizing logfiles.

Also PHP itself has syslog support, so FPM should consequently have it,
too.



I hereby ask to add syslog support to FPM.







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1


Req #52052 [PATCH]: add syslog support to FPM

2010-06-13 Thread f...@php.net
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1

 ID:   52052
 Patch added by:   f...@php.net
 Reported by:  ef-lists at email dot de
 Summary:  add syslog support to FPM
 Status:   Assigned
 Type: Feature/Change Request
 Package:  FPM related
 Operating System: Linux/*NIX
 PHP Version:  5.3SVN-2010-06-11 (SVN)
 Assigned To:  fat

 New Comment:

The following patch has been added/updated:

Patch Name: fpm-syslog.v3.patch
Revision:   1276419780
URL:   
http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v3.patch&revision=1276419780


Previous Comments:

[2010-06-13 10:41:26] f...@php.net

You can try instead the new revision of the patch I've just attached.



It adds sending slowlog to syslog.



Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same
values as 

log_level. By default it's LOG_DEBUG. There is no way to change the
ident and the 

facility for slowlog, it takes the same values as the globals ones 

(syslog_facility and syslog_event). There is no need to because the pool
name is 

prepended to every slowlog message.


[2010-06-13 10:36:27] f...@php.net

The following patch has been added/updated:

Patch Name: fpm-syslog.v2.patch
Revision:   1276418186
URL:   
http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186


[2010-06-12 19:54:05] ef-lists at email dot de

Great job! :-)



I'll try it out and report feedback to you.


[2010-06-12 18:49:35] f...@php.net

The attached patch should activate syslog sypport to error_log only. You
can try 

it on trunk.



change error_log to "syslog"



You can also set

syslog_facility and syslog_ident to feet your needs. But default values
should 

be OK.



I'm working on the slowlog patch also but it's a bit more complicated.

++ Jerome


[2010-06-12 18:47:15] f...@php.net

The following patch has been added/updated:

Patch Name: fpm-syslog.v1.patch
Revision:   1276361235
URL:   
http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235




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=52052


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1


Req #52052 [Com]: add syslog support to FPM

2010-06-13 Thread f...@php.net
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1

 ID:   52052
 Comment by:   f...@php.net
 Reported by:  ef-lists at email dot de
 Summary:  add syslog support to FPM
 Status:   Assigned
 Type: Feature/Change Request
 Package:  FPM related
 Operating System: Linux/*NIX
 PHP Version:  5.3SVN-2010-06-11 (SVN)
 Assigned To:  fat

 New Comment:

my mistakes. The v2 patch was buggy. Use v3 instead.


Previous Comments:

[2010-06-13 11:03:00] f...@php.net

The following patch has been added/updated:

Patch Name: fpm-syslog.v3.patch
Revision:   1276419780
URL:   
http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v3.patch&revision=1276419780


[2010-06-13 10:41:26] f...@php.net

You can try instead the new revision of the patch I've just attached.



It adds sending slowlog to syslog.



Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same
values as 

log_level. By default it's LOG_DEBUG. There is no way to change the
ident and the 

facility for slowlog, it takes the same values as the globals ones 

(syslog_facility and syslog_event). There is no need to because the pool
name is 

prepended to every slowlog message.


[2010-06-13 10:36:27] f...@php.net

The following patch has been added/updated:

Patch Name: fpm-syslog.v2.patch
Revision:   1276418186
URL:   
http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186


[2010-06-12 19:54:05] ef-lists at email dot de

Great job! :-)



I'll try it out and report feedback to you.


[2010-06-12 18:49:35] f...@php.net

The attached patch should activate syslog sypport to error_log only. You
can try 

it on trunk.



change error_log to "syslog"



You can also set

syslog_facility and syslog_ident to feet your needs. But default values
should 

be OK.



I'm working on the slowlog patch also but it's a bit more complicated.

++ Jerome




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=52052


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1


Bug #52067 [Asn->Csd]: chdir to a nonexisting directory when chrooting is buggy

2010-06-13 Thread fat
Edit report at http://bugs.php.net/bug.php?id=52067&edit=1

 ID:   52067
 Updated by:   f...@php.net
 Reported by:  f...@php.net
 Summary:  chdir to a nonexisting directory when chrooting is
   buggy
-Status:   Assigned
+Status:   Closed
 Type: Bug
 Package:  FPM related
 Operating System: linux
 PHP Version:  5.3SVN-2010-06-12 (SVN)
 Assigned To:  fat



Previous Comments:

[2010-06-13 12:30:37] f...@php.net

Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=300418
Log: Fix #52067, chroot and chdir path were not checked at startup. If
configured with unexistant directories, FPM entered in an error loop.


[2010-06-12 19:49:58] f...@php.net

Description:

when setting chroot and chdir to a non existing directory into the
chroot. FPM 

loops creating children which are dying because they can't chdir.





Jun 12 19:46:10.884803 [NOTICE] [pool www] child 27114 started

Jun 12 19:46:10.884930 [WARNING] [pool www] child 27114 exited with code
255 

after 0.000149 seconds from start

Jun 12 19:46:10.885001 [WARNING] [pool www] child 27114 said into
stderr: "Jun 

12 19:46:10.884025 [ERROR] [pool www] chdir(/usr/local/nginx/html)
failed: No 

such file or directory (2)"

Jun 12 19:46:10.885072 [WARNING] [pool www] child 27114 said into
stderr: "Jun 

12 19:46:10.884153 [ERROR] [pool www] child failed to initialize", pipe
is 

closed

Jun 12 19:46:10.886642 [NOTICE] [pool www] child 27115 started

Jun 12 19:46:10.886768 [WARNING] [pool www] child 27115 exited with code
255 

after 0.000149 seconds from start

Jun 12 19:46:10.886842 [WARNING] [pool www] child 27115 said into
stderr: "Jun 

12 19:46:10.885852 [ERROR] [pool www] chdir(/usr/local/nginx/html)
failed: No 

such file or directory (2)"

Jun 12 19:46:10.886914 [WARNING] [pool www] child 27115 said into
stderr: "Jun 

12 19:46:10.885982 [ERROR] [pool www] child failed to initialize", pipe
is 

closed

Jun 12 19:46:10.888469 [NOTICE] [pool www] child 27116 started

Jun 12 19:46:10.888596 [WARNING] [pool www] child 27116 exited with code
255 

after 0.000150 seconds from start

Jun 12 19:46:10.888671 [WARNING] [pool www] child 27116 said into
stderr: "Jun 

12 19:46:10.887691 [ERROR] [pool www] chdir(/usr/local/nginx/html)
failed: No 

such file or directory (2)"

Jun 12 19:46:10.888744 [WARNING] [pool www] child 27116 said into
stderr: "Jun 

12 19:46:10.887820 [ERROR] [pool www] child failed to initialize", pipe
is 

closed

Jun 12 19:46:10.890295 [NOTICE] [pool www] child 27117 started

Jun 12 19:46:10.890422 [WARNING] [pool www] child 27117 exited with code
255 

after 0.000150 seconds from start

Jun 12 19:46:10.890491 [WARNING] [pool www] child 27117 said into
stderr: "Jun 

12 19:46:10.889524 [ERROR] [pool www] chdir(/usr/local/nginx/html)
failed: No 

such file or directory (2)"

Jun 12 19:46:10.890563 [WARNING] [pool www] child 27117 said into
stderr: "Jun 

12 19:46:10.889651 [ERROR] [pool www] child failed to initialize", pipe
is 

closed

Jun 12 19:46:10.893124 [NOTICE] [pool www] child 27119 started

Jun 12 19:46:10.893256 [WARNING] [pool www] child 27119 exited with code
255 

after 0.000155 seconds from start

Jun 12 19:46:10.893329 [WARNING] [pool www] child 27119 said into
stderr: "Jun 

12 19:46:10.892335 [ERROR] [pool www] chdir(/usr/local/nginx/html)
failed: No 

such file or directory (2)"

Jun 12 19:46:10.893401 [WARNING] [pool www] child 27119 said into
stderr: "Jun 

12 19:46:10.892467 [ERROR] [pool www] child failed to initialize", pipe
is 

closed



Test script:
---
chroot=/usr/local/nginx/html

chdir=/usr/local/nginx/html







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52067&edit=1


Bug #52050 [Asn->Fbk]: PHP-FPM Dies after self-initiating reload

2010-06-13 Thread fat
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1

 ID:   52050
 Updated by:   f...@php.net
 Reported by:  marcus at adolfsson dot com
 Summary:   PHP-FPM Dies after self-initiating reload
-Status:   Assigned
+Status:   Feedback
 Type: Bug
 Package:  FPM related
 Operating System: fc7
 PHP Version:  5.3.2
 Assigned To:  fat

 New Comment:

Can you also provide the libevent version and the OS you're using.
Thanks


Previous Comments:

[2010-06-11 16:27:49] marcus at adolfsson dot com

ldd /usr/sbin/php-fpm

libcrypt.so.1 => /lib64/libcrypt.so.1 (0x003a8300)

libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x003a8600)

libpspell.so.15 => /usr/lib64/libpspell.so.15 (0x003a8640)

librt.so.1 => /lib64/librt.so.1 (0x003a8180)

libmysqlclient.so.15 => /usr/lib64/mysql/libmysqlclient.so.15
(0x0036a360)

libmcrypt.so.4 => /usr/lib64/libmcrypt.so.4 (0x00357ba0)

libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0036a320)

libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0036a3e0)

libz.so.1 => /usr/lib64/libz.so.1 (0x0035af40)

libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x003a8700)

libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x0035af80)

libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x003a8540)

libpcre.so.0 => /lib64/libpcre.so.0 (0x0035b040)

libm.so.6 => /lib64/libm.so.6 (0x003a80c0)

libdl.so.2 => /lib64/libdl.so.2 (0x003a8080)

libevent-1.4.so.1 => /usr/local/lib/libevent-1.4.so.1
(0x2aac3000)

libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0036a2e0)

libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
(0x003a8440)

libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x003a8340)

libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x003a83c0)

libcom_err.so.2 => /lib64/libcom_err.so.2 (0x003a8280)

libssl.so.6 => /lib64/libssl.so.6 (0x0035afc0)

libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0035b080)

libresolv.so.2 => /lib64/libresolv.so.2 (0x003a82c0)

libidn.so.11 => /usr/lib64/libidn.so.11 (0x003a8200)

libc.so.6 => /lib64/libc.so.6 (0x003a8040)

libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003a8400)

libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003a84c0)

libpthread.so.0 => /lib64/libpthread.so.0 (0x003a8100)

/lib64/ld-linux-x86-64.so.2 (0x003a8000)

libnsl.so.1 => /lib64/libnsl.so.1 (0x003a8240)

libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0
(0x003a8480)


[2010-06-11 16:10:16] tony2...@php.net

Please also show the output of `ldd /path/to/php-fpm`. Thanks.


[2010-06-11 15:36:27] marcus at adolfsson dot com

This is my conf file:



;

; FPM Configuration ;

;





;include=/etc/fpm.d/*.conf



;;

; Global Options ;

;;



[global]

pid = /usr/logs/php-fpm.pid

error_log = /usr/logs/php-fpm.log



; Log level

; Possible Values: alert, error, warning, notice, debug

log_level = notice



; If this number of child processes exit with SIGSEGV or SIGBUS within
the time

; interval set by emergency_restart_interval then FPM will restart. A
value

; of '0' means 'Off'.

; Default Value: 0

emergency_restart_threshold = 10



; Interval of time used by emergency_restart_interval to determine when

; a graceful restart will be initiated.  This can be useful to work
around

; accidental corruptions in an accelerator's shared memory.

; Available Units: s(econds), m(inutes), h(ours), or d(ays)

; Default Unit: seconds

; Default Value: 0

emergency_restart_interval = 1m



; Time limit for child processes to wait for a reaction on signals from
master.

; Available units: s(econds), m(inutes), h(ours), or d(ays)

; Default Unit: seconds

; Default Value: 0

process_control_timeout = 5s



; Send FPM to background. Set to 'no' to keep FPM in foreground for
debugging.

; Default Value: yes

daemonize = yes





; Pool Definitions ;





; Multiple pools of child processes may be started with different
listening

; ports and different management options.  The name of the pool will be

; used in logs and stats. There is no limitation on the number of pools
which

; FPM can handle. Your system will tell you anyway :)



; Start a new pool named 'www'.

[www]



; The address on which to accept FastCGI requests.

; Valid syntaxes are:

;   

Bug #33957 [Com]: gmdate('W')/date('W') sometimes returns wrong week number.

2010-06-13 Thread cgullz at gmail dot com
Edit report at http://bugs.php.net/bug.php?id=33957&edit=1

 ID:   33957
 Comment by:   cgullz at gmail dot com
 Reported by:  paul at stunning-stuff dot com
 Summary:  gmdate('W')/date('W') sometimes returns wrong week
   number.
 Status:   Closed
 Type: Bug
 Package:  Date/time related
 Operating System: *
 PHP Version:  5CVS-2005-08-02
 Assigned To:  derick

 New Comment:

Hi,



I have the same problem using date('W') to show week number of
13/June/2010 which should be 25, but it displays 23.



I use php 5.2.6 through WAMP2.



This is the first time I hear about snapshot so not sure what am I
suppose to do to fix this problem.



Can someone please explain to me what should I do?



Thank you,



Sigal


Previous Comments:

[2010-05-19 20:56:04] paul at stunning-stuff dot com

Hi Warwick,



The 1st week of a year does not necessarily start on the first of
January 

under the rules of ISO8601. I checked your examples and they seemed
fine. 

Please read up on ISO8601.



-Paul


[2010-05-19 04:06:11] wps at wwe dot com

date('W', $timestamp) fails to return "01" for some January 1st years on
PHP version 5.3.2 and 5.2.8 on CentOS and Windows.





$year = 1970;

$month = 1;

$day = 1;



while ($year <= 2028) {

  $timestamp = mktime(12, 0, 0, $month, $day, $year);

  print $year . " :: " . date('W', $timestamp). " :: " . date('D',
$timestamp) . "\n";

  $year++;

}



Expect 01 for every year

but instead get

1970 :: 01 :: Thu

1971 :: 53 :: Fri

1972 :: 52 :: Sat

1973 :: 01 :: Mon

1974 :: 01 :: Tue

1975 :: 01 :: Wed

1976 :: 01 :: Thu

1977 :: 53 :: Sat

1978 :: 52 :: Sun

...

2020 :: 01 :: Wed

2021 :: 53 :: Fri

2022 :: 52 :: Sat

2023 :: 52 :: Sun

2024 :: 01 :: Mon

2025 :: 01 :: Wed

2026 :: 01 :: Thu

2027 :: 53 :: Fri

2028 :: 52 :: Sat



1st falling on Friday returns 53 

1st falling on Saturday/Sunday return 52





Checked dates using

http://www.tuxgraphics.org/toolbox/cal_year.html





Warwick Shaw


[2005-08-31 16:31:52] der...@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.




[2005-08-02 16:45:08] paul at stunning-stuff dot com

Thanks for your quick reply and thanks for doing such a great job on
PHP. You dev's really make this the best open source language today.



I hope you are able to solve this problem (I'm sure you will). One more
note though: This problem should reoccur every 28 years before and after
1992. This might help you in your testing.



Thanks,



Paul van der Maas

---

www.stunning-stuff.com


[2005-08-02 16:22:09] der...@php.net

Indeed a bug, will have a look at it - thanks for the reproducable case.




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=33957


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=33957&edit=1


[PHP-BUG] Bug #52075 [NEW]: php -b 127.0.0.1 vs php -y php-fpm.conf -x

2010-06-13 Thread luk-4u at hotmail dot com
From: 
Operating system: ubuntu 9.04
PHP version:  5.2.13
Package:  CGI related
Bug Type: Bug
Bug description:php -b 127.0.0.1 vs php -y php-fpm.conf -x

Description:

As starting php-cgi in 2 ways, the 2 results were different. 

1./path/to/php-cgi -b 127.0.0.1:9000

2./path/to/php-cgi -y /path/to/php-fpm.conf -x 



The first one was correct.

The second, which said: 'No input file specified'.



As i tracked down the c code, i found out the reason finally, but dunno why
still.





/php/to/phpsrc/TSRM/tsrm_virtual_cwd.c 

CWD_API int virutal_file_ex(cwd_state *state,.)

around line 1339



the exact code block:



#if !defined(TSRM_WIN32) && !defined(NETWARE)

..

if (use_realpath == CWD_REALPATH) {

return 1;

}

goto no_realpath;





It's the above function that keeps the problem presenting.. 

As i tested, while started as the 1st way, this function return 0, and the
tsrm_realpath returns NULL, also tsrm_realpath was called from
init_request_info. I think u must be familiarer with the code.

And the 2cd way was all right.



Here is my nginx(0.6.39) conf block:

 server {

listen 80;

server_name pk.local.com;

index index.php;

root  /home/zyk/pk_local;

location / {

root /home/zyk/pk_local;

   fastcgi_pass 127.0.0.1:9000;

  #  fastcgi_pass
unix:/usr/local/app/php/logs/php.sock;

fastcgi_index index.php;

fastcgi_intercept_errors on;

include fcgi.conf;

include fastcgi_params.default;

}

}



}

Dir /home/zyk/pk_local is RW for the php daemon userid. 



Here is my php configure option:



configure --enable-fastcgi --enable-fpm --enable-mbstring
--prefix=/usr/local/app/php



Here is my php-fpm.conf







All relative paths in this config are relative to php's install prefix







Pid file

/usr/local/app/php/logs/php-fpm.pid



Error log file

/usr/local/app/php/logs/php-fpm.log



Log level

notice



When this amount of php processes exited with SIGSEGV or SIGBUS 
...

10



... in a less than this interval of time, a graceful restart 
will be
initiated.

Useful to work around accidental curruptions in accelerator's 
shared
memory.

1m



Time limit on waiting child's reaction on signals from master

5s



Set to 'no' to debug fpm

no















Name of pool. Used in logs and stats.

default



Address to accept fastcgi requests on.

Valid syntax is 'ip.ad.re.ss:port' or just 'port' or
'/path/to/unix/socket'

127.0.0.1:9000







Set listen(2) backlog

-1



Set permissions for unix socket, if one used.

In Linux read/write permissions must be set in 
order to allow
connections from web server.

Many BSD-derrived systems allow connections 
regardless of permissions.

nobody

nobody

0666





Additional php.ini defines, specific to this pool of 
workers.







nginx 






Unix user of processes

nobody   




Unix group of processes

nobody  



Process manager settings





Sets style of controling worker process count.

Valid values are 'static' and 'apache-like'

static



Sets the limit on the number of simultaneous 
requests that will be
served.

Equivalent to Apache MaxClients directive.

Equivalent to PHP_FCGI_CHILDREN environment in 
original php.fcgi

Used with any pm_style.

5



Settings group for 'apache-like' pm style

   

Bug #52075 [Opn]: php -b 127.0.0.1 vs php -y php-fpm.conf -x

2010-06-13 Thread luk-4u at hotmail dot com
Edit report at http://bugs.php.net/bug.php?id=52075&edit=1

 ID:   52075
 User updated by:  luk-4u at hotmail dot com
 Reported by:  luk-4u at hotmail dot com
 Summary:  php -b 127.0.0.1 vs php -y php-fpm.conf -x
 Status:   Open
 Type: Bug
 Package:  CGI related
 Operating System: ubuntu 9.04
 PHP Version:  5.2.13

 New Comment:

"As i tested, while started as the 1st way, this function return 0, and
the tsrm_realpath returns NULL' 

This sentence was written wrong, correct is : the 1st way returns 0; the
second returns 1;


Previous Comments:

[2010-06-13 13:38:07] luk-4u at hotmail dot com

Description:

As starting php-cgi in 2 ways, the 2 results were different. 

1./path/to/php-cgi -b 127.0.0.1:9000

2./path/to/php-cgi -y /path/to/php-fpm.conf -x 



The first one was correct.

The second, which said: 'No input file specified'.



As i tracked down the c code, i found out the reason finally, but dunno
why still.





/php/to/phpsrc/TSRM/tsrm_virtual_cwd.c 

CWD_API int virutal_file_ex(cwd_state *state,.)

around line 1339



the exact code block:



#if !defined(TSRM_WIN32) && !defined(NETWARE)

..

if (use_realpath == CWD_REALPATH) {

return 1;

}

goto no_realpath;





It's the above function that keeps the problem presenting.. 

As i tested, while started as the 1st way, this function return 0, and
the tsrm_realpath returns NULL, also tsrm_realpath was called from
init_request_info. I think u must be familiarer with the code.

And the 2cd way was all right.



Here is my nginx(0.6.39) conf block:

 server {

listen 80;

server_name pk.local.com;

index index.php;

root  /home/zyk/pk_local;

location / {

root /home/zyk/pk_local;

   fastcgi_pass 127.0.0.1:9000;

  #  fastcgi_pass
unix:/usr/local/app/php/logs/php.sock;

fastcgi_index index.php;

fastcgi_intercept_errors on;

include fcgi.conf;

include fastcgi_params.default;

}

}



}

Dir /home/zyk/pk_local is RW for the php daemon userid. 



Here is my php configure option:



configure --enable-fastcgi --enable-fpm --enable-mbstring
--prefix=/usr/local/app/php



Here is my php-fpm.conf







All relative paths in this config are relative to php's install prefix







Pid file

/usr/local/app/php/logs/php-fpm.pid



Error log file

/usr/local/app/php/logs/php-fpm.log



Log level

notice



When this amount of php processes exited with SIGSEGV or SIGBUS 
...

10



... in a less than this interval of time, a graceful restart 
will be
initiated.

Useful to work around accidental curruptions in accelerator's 
shared
memory.

1m



Time limit on waiting child's reaction on signals from master

5s



Set to 'no' to debug fpm

no















Name of pool. Used in logs and stats.

default



Address to accept fastcgi requests on.

Valid syntax is 'ip.ad.re.ss:port' or just 'port' or
'/path/to/unix/socket'

127.0.0.1:9000







Set listen(2) backlog

-1



Set permissions for unix socket, if one used.

In Linux read/write permissions must be set in 
order to allow
connections from web server.

Many BSD-derrived systems allow connections 
regardless of
permissions.

nobody

nobody

0666





Additional php.ini defines, specific to this pool of 
workers.







nginx 






Unix user of processes

nobody   




Unix group of processes

nobody  



Process manager settings





Sets style of controling worker process count.

Valid values are 'static'

Req #30157 [Asn->Opn]: ftell() function does not use stream_tell()

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=30157&edit=1

 ID:   30157
 Updated by:   fel...@php.net
 Reported by:  tendencies at free dot fr
 Summary:  ftell() function does not use stream_tell()
-Status:   Assigned
+Status:   Open
 Type: Feature/Change Request
-Package:  Feature/Change Request
+Package:  *General Issues
 Operating System: *
 PHP Version:  5CVS-2004-09-19 (dev)
-Assigned To:  pollita
+Assigned To:  



Previous Comments:

[2009-02-24 17:18:11] doctorrock83 at gmail dot com

Confirmed at the date of this message, the bug is still present in PHP
5.2.8, and PHP 5.3 branch.


[2006-07-26 16:43:31] w...@php.net

(PS: I got here via Bug #37096)


[2006-07-26 16:42:25] w...@php.net

I truly hope that this patch didn't get committed; it's not part of the
streams design and is fundamentally redundant.



I don't have time to make any further commentary than that; further
analysis of the user-stream case mentioned in this bug report is
required, but it certainly does not require making this kind of change
to the core.


[2005-06-16 17:22:20] tony2...@php.net

>Why did you need to add tell() function to the streams internals?

Because the original problem (stream_tell() is not used) looks like a
bug to me.


[2005-06-16 17:17:11] w...@php.net

This tell patch
(http://tony2001.phpclub.net/dev/tmp/userstreamop_tell.diff) is "wrong";
the position should be set implicitly when the stream is opened, and be
updated by the streams layer when it knows that it is changed (as
happens when you seek).



If you need to determine the current position, you simply need to seek
with a zero offset from the current position.



Why did you need to add tell() function to the streams internals?




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=30157


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=30157&edit=1


Bug #37096 [NoF->Opn]: referencing bug with return value for stream_seek

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=37096&edit=1

 ID:   37096
 Updated by:   fel...@php.net
 Reported by:  w...@php.net
 Summary:  referencing bug with return value for stream_seek
-Status:   No Feedback
+Status:   Open
 Type: Bug
 Package:  Streams related
 Operating System: *
 PHP Version:  5CVS-2006-04-16 (CVS)



Previous Comments:

[2006-09-16 01:00:00] 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".


[2006-09-08 21:04:46] tony2...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




[2006-07-26 09:21:28] tendencies at free dot fr

See this bug : http://bugs.php.net/bug.php?id=30157


[2006-04-16 02:29:02] w...@php.net

Description:

When using user-space streams via stream_wrapper_register(),

if you return the value of a property of the object from stream_seek(),
it gets mangled.



Sounds like a problem with the way that the retval from
call_user_function_ex() is disposed.



The workaround is to create a temporary value using a trick like this:



function stream_seek($offset, $whence) {

   ...

   $retval = $this->pos + 0;

   return $retval;

}



presumably the rest of the user wrapper code has the same flaw.

Reproduce code:
---
Abbreviated example; my actual test case is too large.

Valgrind does not indicate any memory errors, so the problem  is likely
logical rather than sloppy memory handling.



class MyStream {

  var $this->pos = 0;

 

  function stream_tell() {

return $this->pos;

  }



  function stream_seek($offset, $whence) {

return $this->pos;

  }

}



Actual result:
--
Problem manifested for me by converting $this->pos to bool(true), which
was then interpreted by the user space wrapper as an invalid return
value from stream_tell(), which simply returns $this->pos.






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=37096&edit=1


Req #29337 [Asn->Fbk]: dns_get_record() unavailable on *BSD

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=29337&edit=1

 ID:   29337
 Updated by:   fel...@php.net
 Reported by:  php at to-the-max dot net
 Summary:  dns_get_record() unavailable on *BSD
-Status:   Assigned
+Status:   Feedback
 Type: Feature/Change Request
-Package:  Feature/Change Request
+Package:  *General Issues
 Operating System: FreeBSD
 PHP Version:  5.0.0
-Assigned To:  pollita
+Assigned To:  

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:

[2008-04-18 12:00:06] manuel at mausz dot at

I ran into the same problem yesterday. So I decided to modify the source
to fallback to the deprecated ns_mkquery/ns_send if the newer functions
aren't available.



Patch for 5.3 and HEAD:
http://manuel.mausz.at/coding/patches/php/5.3.0/php-5.3.0-dns_get_record.patch

Tested on FreeBSD but should work on other BSDs and probably on OS X
too.


[2004-08-02 11:08:39] der...@php.net

Assigning to the person who last touched this.


[2004-07-22 19:30:31] php at to-the-max dot net

Description:

dns_get_record() is not available when PHP is compiled under BSD.



/ext/standard/dns.c uses the res_nmkquery() and res_nsearch() functions
present in newer versions of BIND's libresolv.



However those functions are not present on *BSD (and probably other)
systems.



Please consider using the older res_mkquery(), res_search() fuctions, to
maximize compatibility.







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=29337&edit=1


Req #46934 [Asn->Opn]: Unable to untighten open_basedir restriction

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=46934&edit=1

 ID:   46934
 Updated by:   fel...@php.net
 Reported by:  kristof dot coomans at telenet dot be
 Summary:  Unable to untighten open_basedir restriction
-Status:   Assigned
+Status:   Open
 Type: Feature/Change Request
-Package:  Feature/Change Request
+Package:  *General Issues
 Operating System: *
 PHP Version:  5.3CVS-2009-04-10
-Assigned To:  pollita
+Assigned To:  



Previous Comments:

[2009-04-12 16:17:59] crrodriguez at opensuse dot org

I think that allowing un-tightening is not a very good idea...







Expected result:

The last call should be allowed, and a file test.txt should have been
created in the same directory as the script.

Actual result:
--
Warning: file_put_contents(): open_basedir restriction in effect.
File(C:\sites\

trunk\test.txt) is not within the allowed path(s):
(░δç☺♀) in ...



Warning: file_put_contents(C:\sites\trunk\test.txt): failed to open
stream: Operation not permitted in ...






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=46934&edit=1


Bug #29521 [Asn]: compress.bzip2 wrapper

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=29521&edit=1

 ID:   29521
 Updated by:   fel...@php.net
 Reported by:  nlop...@php.net
 Summary:  compress.bzip2 wrapper
 Status:   Assigned
 Type: Bug
 Package:  Bzip2 Related
 Operating System: win32 only
 PHP Version:  5.2CVS-2007-01-10
-Assigned To:  nlopess
+Assigned To:  iliaa

 New Comment:

Ilia, was this bug fixed with the fix for bug #42117?


Previous Comments:

[2008-11-30 22:46:19] paj...@php.net

Assign to the reporter, he has a cvs account too now >)


[2007-08-10 11:41:23] nlop...@php.net

I don't think this has anything to do with that bug. I checked both
filter and wrapper sources and they are too different.


[2007-08-05 18:17:43] phofstetter at sensational dot ch

Hi,



being the reporter of bug #42117, I think this really is the same thing
and I actually reported a duplicate (terribly sorry for this), though
"my" bug is about the bzip2.compress *filter* where this is about the
stream *wrapper*, but the bug really feels like being the same problem.



Also, the warning is consistent to what I have seen in my case and to
what the incorrect checking of that error code (see #42117) would
cause.



I'm really having my hopes up that this is going to be fixed now :-)



Philip


[2007-08-04 21:03:19] j...@php.net

See bug #42117 which might be the same issue. Nuno, can you try the
patch?




[2007-01-12 22:10:27] nlop...@php.net

yep, it still issue the same warning.




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=29521


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=29521&edit=1


Bug #33997 [Asn->Fbk]: Returned: Bug #16069 - ICONV transliteration failure

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=33997&edit=1

 ID:   33997
 Updated by:   fel...@php.net
 Reported by:  RVaughn at pheedo dot com
 Summary:  Returned: Bug #16069 - ICONV transliteration failure
-Status:   Assigned
+Status:   Feedback
 Type: Bug
 Package:  ICONV related
 Operating System: *
 PHP Version:  5.*, 6CVS (2009-04-25)
-Assigned To:  derick
+Assigned To:  

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:

[2009-04-27 16:13:23] j...@php.net

Still fails.


[2005-08-08 00:10:15] sni...@php.net

Assigning to Derick who's comment about my patch was "It's funny" and
other comment about the iconv code "this is a mess"

:)




[2005-08-07 14:42:23] der...@php.net

Please provide a location where we can download your failed test's .out
and .exp file.


[2005-08-04 23:34:18] RVaughn at pheedo dot com

Do let me know if you want me to put the output somewhere on our site
where it can be downloaded, the code itself is just the PHP-provided
test: bug16069.phpt.  Thanks!  Cheers!


[2005-08-04 23:32:57] RVaughn at pheedo dot com

OK, here's the diff output from the test results, please note that the
output is the same until part way through, and the ultimate length is
different:



===

/usr/local/src/Tars/php-4.4.0/ext/iconv/tests/bug16069.phpt

===



 EXPECTED OUTPUT

¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë)

 ACTUAL OUTPUT

¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë)

 FAILED




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=33997


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=33997&edit=1


Bug #41758 [Asn->Wfx]: SORT_LOCALE_STRING broken for sort() in PHP6

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=41758&edit=1

 ID:   41758
 Updated by:   fel...@php.net
 Reported by:  hedvall at gmail dot com
 Summary:  SORT_LOCALE_STRING broken for sort() in PHP6
-Status:   Assigned
+Status:   Wont fix
 Type: Bug
 Package:  Arrays related
 Operating System: Win2k SP4
 PHP Version:  6CVS-2007-06-21 (snap)
 Assigned To:  andrei



Previous Comments:

[2007-06-21 10:19:30] hedvall at gmail dot com

Description:

According to the documentation for sort(), you must use
i18n_loc_set_default() for sort() with SORT_LOCALE_STRING to work in
PHP6. However, i18n_loc_set_default() is an undefined function. The
documentation instead refers to locale_set_default(). When setting the
locale to "sv_SE" (correct) the function returns false, but when setting
it to "sv_PHP" (incorrect) the function returns true which is the wrong
behavior. The example from locale_set_default() uses "pt_PT" which can
be set, but when sorting the result turns out the wrong way. When using
locale_get_default() it returns what was set with locale_set_default()
even if that function turned it down by returning false.

When later using sort() or asort() (or any other sort) with
SORT_LOCALE_STRING the result is the same as a normal sort.

Reproduce code:
---


Expected result:

Array

(

[0] => caçada

[1] => cacto

[2] => caramelo

)

Actual result:
--
Array

(

[0] => cacto

[1] => caramelo

[2] => caçada

)






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=41758&edit=1


Bug #41631 [Asn]: default_socket_timeout does not work with SSL

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=41631&edit=1

 ID:   41631
 Updated by:   fel...@php.net
 Reported by:  david at acz dot org
 Summary:  default_socket_timeout does not work with SSL
 Status:   Assigned
 Type: Bug
 Package:  OpenSSL related
 Operating System: *
-PHP Version:  5.2.11
+PHP Version:  5.2, 5.3
 Assigned To:  pajoye

 New Comment:

Pierre, doesn't the attached patch fix this issue?


Previous Comments:

[2010-03-15 10:33:47] jason at kapoks dot co dot uk

Had this issue over the weekend with 5.2.10.

Essentially this means our entire service is vulnerable to Denial of
Service.



Linux localhost.localdomain 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT
2009 i686 i686 i386 GNU/Linux



CentOS release 5.3 (Final)



PHP 5.2.10 (cli) (built: Jun 21 2009 11:10:43)

Copyright (c) 1997-2009 The PHP Group

Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend
Technologies

with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend
Technologies


[2010-01-18 19:16:42] wdierkes at 5dollarwhitebox dot org

This is also reproducible on 5.2.12 as described.  As mentioned 

previously, this has the potentially to have major effects (Denial of 

Servide) etc due to processes hanging and never timing out.  



# cat /etc/redhat-release 

Red Hat Enterprise Linux Server release 5.4 (Tikanga)



# php -v

PHP 5.2.12 (cli) (built: Dec 17 2009 12:23:35) 

Copyright (c) 1997-2009 The PHP Group

Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies



# uname -a

Linux linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 

x86_64 x86_64 GNU/Linux


[2009-10-16 20:14:25] arkadi dot shishlov at gmail dot com

At least it would be helpful to set TCP keep-alive on socket so OS could
timeout it eventually, otherwise there are connections stuck for days.


[2009-09-24 19:30:14] srina...@php.net

bug #48524 depends on this fix
(http://bugs.php.net/bug.php?id=48524&edit=1)



i wish , bug tracking system allowed to be able to close a bug as
duplicate of another. then, we could close 48524 as dup of this (41631).
this can also trigger the internal score for this bug to be increased
(helping in set priority etc). 


[2009-09-18 10:10:02] marcin at php4u dot co dot uk

Still can reproduce on Windows XP SP3, PHP 5.2.6



while connecting to https, script doesn't time out




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=41631


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=41631&edit=1


Bug #43327 [Asn->Opn]: wrong return value from mail(), if sendmail_path is wrong

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=43327&edit=1

 ID:   43327
 Updated by:   fel...@php.net
 Reported by:  carsten_sttgt at gmx dot de
 Summary:  wrong return value from mail(), if sendmail_path is
   wrong
-Status:   Assigned
+Status:   Open
 Type: Bug
 Package:  Mail related
 Operating System: win32 only (?)
 PHP Version:  5.*, 6 (2009-08-07)
-Assigned To:  garretts
+Assigned To:  



Previous Comments:

[2009-08-20 10:39:59] j...@php.net

Reopened, fix was reverted.


[2009-08-20 09:03:20] s...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287495
Log: - revert fix for #43327, it breaks system&co functions


[2009-08-20 01:56:05] carsten_sttgt at gmx dot de

Hi Garrett,



> Can you retest with the latest 5.3 snapshot, and post feedback?



I can do this. Just some remarks first:





> This occurs because popen_ex executes the command using the comspec

> ('cmd.exe'), which will always create a valid process--but intended

> actual child process fails.



That's correct. No error during creation of the process ("cmd.exe" /
"GetLastError == 0"). But in this case, "cmd.exe" returns an exit code
!= 0, which is available with "GetExitCodeProcess()".  So you know
there's a problem.



Regarding mail():

- mail() does not detect that "cmd.exe" can't start "sendmail.exe"



- it also does not detect, if "cmd.exe" can start "sendmail.exe",

  but "sendmail.exe" is returning an exit code != 0

  --> if "cmd.exe" can start a program, it's returning the exit

  code from that program, and so this is available with 

  GetExitCodeProcess().



So there is the question, why does mail() does not test the return value
of pclose() in a correct way on windows? At the moment it looks like:

| #ifdef PHP_WIN32

| if (ret == -1)

| {

| MAIL_RET(0);

| } else {

|MAIL_RET(1);

| }



But I think it should be also something like?:

| if (ret != 0)





> I'm patching this so that it skips using cmd.exe--there is really

> no reason this should be here,



Some hints:

- If you want start an executable with just the name and without the

  extension (like ".com, *.pl"), you must do this through "cmd.exe"

  (only for "*.exe" files you can use just the name).

- In the MSDN you can read, that you have to use "cmd.exe" to start

  a batchfile with CreateProcess. Ok, for me that's working without

  "cmd.exe". But maybe this depends on the Windows version or

  compiler.



Regards,

Carsten


[2009-08-19 18:56:08] garre...@php.net

Carsten, 



Can you retest with the latest 5.3 snapshot, and post feedback?



Thanks




[2009-08-19 18:43:46] s...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287480
Log: - fixed #43327, wrong return value from mail(), if sendmail_path is
wrong




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=43327


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=43327&edit=1


Bug #52075 [Opn->Csd]: php -b 127.0.0.1 vs php -y php-fpm.conf -x

2010-06-13 Thread fat
Edit report at http://bugs.php.net/bug.php?id=52075&edit=1

 ID:   52075
 Updated by:   f...@php.net
 Reported by:  luk-4u at hotmail dot com
 Summary:  php -b 127.0.0.1 vs php -y php-fpm.conf -x
-Status:   Open
+Status:   Closed
 Type: Bug
 Package:  FPM related
 Operating System: ubuntu 9.04
 PHP Version:  5.2.13
-Assigned To:  
+Assigned To:  fat

 New Comment:

FPM is not supported on 5.2.x and your revision is old as the conf file
is 

formatted in XML (now it's INI).



Please use 5.3.x from http://snaps.php.net/



If you're using the FPM patch from http://php-fpm.org to use FPM on
5.2.x, 

please ask on the FPM mailing list
(http://groups.google.com/group/highload-php-

en).



++ Jerome


Previous Comments:

[2010-06-13 13:41:48] luk-4u at hotmail dot com

"As i tested, while started as the 1st way, this function return 0, and
the tsrm_realpath returns NULL' 

This sentence was written wrong, correct is : the 1st way returns 0; the
second returns 1;


[2010-06-13 13:38:07] luk-4u at hotmail dot com

Description:

As starting php-cgi in 2 ways, the 2 results were different. 

1./path/to/php-cgi -b 127.0.0.1:9000

2./path/to/php-cgi -y /path/to/php-fpm.conf -x 



The first one was correct.

The second, which said: 'No input file specified'.



As i tracked down the c code, i found out the reason finally, but dunno
why still.





/php/to/phpsrc/TSRM/tsrm_virtual_cwd.c 

CWD_API int virutal_file_ex(cwd_state *state,.)

around line 1339



the exact code block:



#if !defined(TSRM_WIN32) && !defined(NETWARE)

..

if (use_realpath == CWD_REALPATH) {

return 1;

}

goto no_realpath;





It's the above function that keeps the problem presenting.. 

As i tested, while started as the 1st way, this function return 0, and
the tsrm_realpath returns NULL, also tsrm_realpath was called from
init_request_info. I think u must be familiarer with the code.

And the 2cd way was all right.



Here is my nginx(0.6.39) conf block:

 server {

listen 80;

server_name pk.local.com;

index index.php;

root  /home/zyk/pk_local;

location / {

root /home/zyk/pk_local;

   fastcgi_pass 127.0.0.1:9000;

  #  fastcgi_pass
unix:/usr/local/app/php/logs/php.sock;

fastcgi_index index.php;

fastcgi_intercept_errors on;

include fcgi.conf;

include fastcgi_params.default;

}

}



}

Dir /home/zyk/pk_local is RW for the php daemon userid. 



Here is my php configure option:



configure --enable-fastcgi --enable-fpm --enable-mbstring
--prefix=/usr/local/app/php



Here is my php-fpm.conf







All relative paths in this config are relative to php's install prefix







Pid file

/usr/local/app/php/logs/php-fpm.pid



Error log file

/usr/local/app/php/logs/php-fpm.log



Log level

notice



When this amount of php processes exited with SIGSEGV or SIGBUS 
...

10



... in a less than this interval of time, a graceful restart 
will be
initiated.

Useful to work around accidental curruptions in accelerator's 
shared
memory.

1m



Time limit on waiting child's reaction on signals from master

5s



Set to 'no' to debug fpm

no















Name of pool. Used in logs and stats.

default



Address to accept fastcgi requests on.

Valid syntax is 'ip.ad.re.ss:port' or just 'port' or
'/path/to/unix/socket'

127.0.0.1:9000







Set listen(2) backlog

-1



Set permissions for unix socket, if one used.

In Linux read/write permissions must be set in 
order to allow
connections from web server.

Many BSD-derrived systems allow connections 
regardless of
permissions.

nobody

nobody

0666





Additional php.ini defines, specific to this pool of 
workers.







nginx  

Req #51973 [Com]: a way to restart single pools, enable/disable modules per pool

2010-06-13 Thread f...@php.net
Edit report at http://bugs.php.net/bug.php?id=51973&edit=1

 ID:  51973
 Comment by:  f...@php.net
 Reported by: slogster at gmail dot com
 Summary: a way to restart single pools, enable/disable modules per
  pool
 Status:  Assigned
 Type:Feature/Change Request
 Package: FPM related
 PHP Version: 5.3SVN-2010-06-02 (SVN)
 Assigned To: fat

 New Comment:

For enabeling extensions you can use the php_admin_value setting for
each pool:



php_admin_value[extension] = extension.so


Previous Comments:

[2010-06-02 13:01:49] slogster at gmail dot com

Description:

Hi,







I would like to be able do enable/disable modules per pool and would
also like to be able to restart single pool when I change its config.







Thanks







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51973&edit=1


Bug #45808 [Asn]: [PATCH] stream_socket_enable_crypto() blocks and eats CPU

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=45808&edit=1

 ID:   45808
 Updated by:   fel...@php.net
 Reported by:  six at aegis-corp dot org
-Summary:  stream_socket_enable_crypto() blocks and eats CPU
+Summary:  [PATCH] stream_socket_enable_crypto() blocks and eats
   CPU
 Status:   Assigned
 Type: Bug
 Package:  Streams related
 Operating System: Linux 2.6
 PHP Version:  5.*, 6
 Assigned To:  pajoye

 New Comment:

Pierre, what about this patch?


Previous Comments:

[2009-10-13 10:45:21] vincent at optilian dot com

Actually I fixed some things in the patch, see below ...



It makes more sense to test whether the socket is in blocking mode, even
if a client ssl socket doesn't need multiple calls to
stream_socket_enable_crypto()



--- xp_ssl.c.orig   2009-10-12 19:34:31.0 +0200

+++ xp_ssl.c2009-10-13 12:30:24.0 +0200

@@ -299,8 +299,12 @@

SSL_METHOD *method;



if (sslsock->ssl_handle) {

-   php_error_docref(NULL TSRMLS_CC, E_WARNING, "SSL/TLS already 
set-up
for this stream");

-   return -1;

+   if (sslsock->s.is_blocked) {

+   php_error_docref(NULL TSRMLS_CC, E_WARNING, "SSL/TLS 
already set-up
for this stream");

+   return -1;

+   } else {

+   return 0;

+   }

}

 

/* need to do slightly different things, based on client/server
method,

@@ -415,7 +419,7 @@

}

 

if (n <= 0) {

-   retry = handle_ssl_error(stream, n, 1 
TSRMLS_CC);

+   retry = handle_ssl_error(stream, n, 
sslsock->is_client ||
sslsock->s.is_blocked TSRMLS_CC);

} else {

break;

}


[2009-10-12 20:50:36] vincent at optilian dot com

Here is a patch to fix this issue (diff against 5.3.0)



As far as I have tested, everything works as expected with this patch
applied.



--- xp_ssl.c.orig   2009-10-12 19:34:31.0 +0200

+++ xp_ssl.c2009-10-12 20:39:19.0 +0200

@@ -299,8 +299,12 @@

SSL_METHOD *method;



if (sslsock->ssl_handle) {

-   php_error_docref(NULL TSRMLS_CC, E_WARNING, "SSL/TLS already 
set-up
for this stream");

-   return -1;

+   if (sslsock->is_client) {

+   php_error_docref(NULL TSRMLS_CC, E_WARNING, "SSL/TLS 
already set-up
for this stream");

+   return -1;

+   } else {

+   return 0;

+   }

}

 

/* need to do slightly different things, based on client/server
method,

@@ -415,7 +419,7 @@

}

 

if (n <= 0) {

-   retry = handle_ssl_error(stream, n, 1 
TSRMLS_CC);

+   retry = handle_ssl_error(stream, n, 
sslsock->is_client TSRMLS_CC);

} else {

break;

}


[2009-08-18 16:15:00] garre...@php.net

FYI: 

I can't repro this on Windows with the build off the snaps' box (VC9 x86
Non Thread Safe (2009-Aug-18 16:00:00)). 



It: 

  blocks until connection using telnet[expected]

  doens't consume any CPU[expected]

  and returns 'bool(false)' [expected -- I assume the same as 'int(0)']

  and exits[expected]  



G


[2008-10-30 11:03:57] xl269 at cam dot ac dot uk

just to confirm that this bug still exists in php5.3-200810292330


[2008-09-25 17:59:37] singularity_control at rcpt dot at

This makes a serious security issue. It is a very effective DoS on

all single process PHP servers with SSL and a slightly less bad DoS on
multi-process PHP servers.




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=45808


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=45808&edit=1


Bug #46834 [Asn->Wfx]: Range of mcrypt functions fail on PHP 6.0

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=46834&edit=1

 ID:   46834
 Updated by:   fel...@php.net
 Reported by:  a...@php.net
 Summary:  Range of mcrypt functions fail on PHP 6.0
-Status:   Assigned
+Status:   Wont fix
 Type: Bug
 Package:  mcrypt related
 Operating System: *
 PHP Version:  6CVS-2008-12-11 (snap)
 Assigned To:  derick



Previous Comments:

[2008-12-11 10:39:32] a...@php.net

Description:

A range of PHPTs fail on PHP 6 where they pass on PHP 5.2/5.3. In 

many cases it looks like the function returns different output from 

encryption/decryption calls. The following failing tests are all 

checked into PHP 6 and marked with an XFAIL section:



mcrypt_cbc_3des_encrypt.phpt

mcrypt_cbc_3des_decrypt.phpt

mcrypt_cbc_variation4.phpt

mcrypt_cbc_variation5.phpt

mcrypt_rijndael128_128BitKey.phpt

mcrypt_rijndael128_256BitKey.phpt

mcrypt_decrypt_3des_cbc.phpt

mcrypt_decrypt_variation5.phpt

mcrypt_encrypt_3des_cbc.phpt

mcrypt_encrypt_variation5.phpt

mcrypt_ecb_variation4.phpt



The problem may be common to all the failing tests and looks like 

something has changed with different length initialisation vectors.

Reproduce code:
---
(See the tests checked into CVS)

Expected result:

For example, the mcrypt_cbc_3des_decrypt.phpt test expects:



--- testing different iv lengths



iv length=4



Warning: mcrypt_cbc(): The IV parameter must be as long as the 

blocksize in %s on line %d

unicode(32) "736563726574206d657373616765"



iv length=8

unicode(32) "736563726574206d657373616765"



iv length=9



Warning: mcrypt_cbc(): The IV parameter must be as long as the 

blocksize in %s on line %d

unicode(32) "736563726574206d657373616765"







Actual result:
--
iv length=4



Warning: mcrypt_cbc(): The IV parameter must be as long as the 

blocksize in D:\Testing\php-6.0\mcrypt_cbc_3des_decrypt.php on line 

52

unicode(32) "425750466574206d657373616765"



iv length=8

unicode(32) "736563726574206d657373616765"



iv length=9



Warning: mcrypt_cbc(): The IV parameter must be as long as the 

blocksize in D:\Testing\php-6.0\mcrypt_cbc_3des_decrypt.php on line 

52

unicode(32) "4257504650421755657373616765"






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=46834&edit=1


Bug #46981 [Asn->Csd]: PDO get Data Bug for Firebird DBMS

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=46981&edit=1

 ID:   46981
 Updated by:   fel...@php.net
 Reported by:  flylink at 126 dot com
 Summary:  PDO get Data Bug for Firebird DBMS
-Status:   Assigned
+Status:   Closed
 Type: Bug
 Package:  PDO related
 Operating System: Windows
 PHP Version:  5.2.9
-Assigned To:  abies
+Assigned To:  felipe

 New Comment:

It was already fixed in 5.2.10. (see bug #47845)



Thanks.


Previous Comments:

[2009-02-09 13:26:10] fel...@php.net

I can reproduce it on 5.2.9-CVS.


[2009-01-03 11:10:49] flylink at 126 dot com

Maybe it is not clear from my last description, please read the
following:



In PHP script, when access Firbird database with PDO drive and get
the data from a reslut set by executing SQL qury sentence when there is
a result set, the first row data is null.


[2009-01-01 01:59:15] ka...@php.net

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.





[2008-12-31 03:16:01] flylink at 126 dot com

Description:

I use PDO driver to access Firebird DBMS,

find a bug,I couldn't get first row's data

Reproduce code:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

http://www.w3.org/1999/xhtml";>





PDO for Firebird









PDO BUG for Firebird:";

 $sql='SELECT * from link';

 $rs=$dbConn->query($sql); 

 foreach ($rs as $row) {  print "1==>".$row[1]."
2==>".$row['SITELINK']."";  }

 

 $dbConn=NULL; 

?>







Expected result:

PDO BUG for Firebird:

1==>Firebird 2==>http://www.firebirdsql.org

1==>?̐򔱃SDN 2==>http://www.csdn.net

1==>???í¼¾ 2==>http://firebird.dearinfo.com/

1==>IBPhoenix 2==>http://www.ibphoenix.com

1==>??Ô½PHP 2==>http://www.phpe.net

1==>Fracle-Janus Soft 2==>http://www.janus-software.com

1==>Firebird֐΄ɧǸ 2==>http://www.firebird.net.cn

1==>?㖝ʀ?͈?Ї׊Ѷ 2==>http://www.it136.net

1==>DelphiÔ°?Ø 2==>http://www.delphifans.com

1==>Delphi K.TopӑՓ?^ 2==>http://delphi.ktop.com.tw

1==>DotNetFirebird 2==>http://www.dotnetfirebird.org/

1==>Firebird?ٷ?͸վ 2==>http://www.firebirdsql.org/

1==>Β?IJ??͠2==>http://blog.csdn.net/jianlei/

1==>DelphiÒ¤?? 2==>http://www.51delphi.com

1==>Delphi?ЗӠ2==>http://www.2ccc.com

1==>??͸ҳ 2==>http://www.destructor.de/firebird/index.htm

1==>???UŌ 2==>http://jianlei.ys168.com



Actual result:
--
PDO BUG for Firebird:

1==> 2==>

1==>?̐򔱃SDN 2==>http://www.csdn.net

1==>???í¼¾ 2==>http://firebird.dearinfo.com/

1==>IBPhoenix 2==>http://www.ibphoenix.com

1==>??Ô½PHP 2==>http://www.phpe.net

1==>Fracle-Janus Soft 2==>http://www.janus-software.com

1==>Firebird֐΄ɧǸ 2==>http://www.firebird.net.cn

1==>?㖝ʀ?͈?Ї׊Ѷ 2==>http://www.it136.net

1==>DelphiÔ°?Ø 2==>http://www.delphifans.com

1==>Delphi K.TopӑՓ?^ 2==>http://delphi.ktop.com.tw

1==>DotNetFirebird 2==>http://www.dotnetfirebird.org/

1==>Firebird?ٷ?͸վ 2==>http://www.firebirdsql.org/

1==>Β?IJ??͠2==>http://blog.csdn.net/jianlei/

1==>DelphiÒ¤?? 2==>http://www.51delphi.com

1==>Delphi?ЗӠ2==>http://www.2ccc.com

1==>??͸ҳ 2==>http://www.destructor.de/firebird/index.htm

1==>???UŌ 2==>http://jianlei.ys168.com








-- 
Edit this bug report at http://bugs.php.net/bug.php?id=46981&edit=1


Bug #46990 [Asn->Wfx]: Passing UTF8 strings to filesystem functions produce wrong filenames

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=46990&edit=1

 ID:   46990
 Updated by:   fel...@php.net
 Reported by:  alex dot bazan at concatel dot com
 Summary:  Passing UTF8 strings to filesystem functions produce
   wrong filenames
-Status:   Assigned
+Status:   Wont fix
 Type: Bug
 Package:  Filesystem function related
 Operating System: win32 only - Windows XP
 PHP Version:  6*
 Assigned To:  pajoye



Previous Comments:

[2009-01-09 11:24:18] paj...@php.net

Can't be fixed in 5.2 neither in 5.3. It will work smoothly in 6.x
(unicode support).


[2009-01-09 10:54:13] alex dot bazan at concatel dot com

For anyone stumbling upon this bug, i wrote a workaround building a
wrapper for filesystem functions. This workaround will will not fix the
issue completely but will work with latin compatible characters when
using UTF8 as the string encoding. People using other characters
(japanese, chinese, hebrew ...) will still have problems.





CODE:





/**

 * Wrapper for PHP filesystem functions

 */

class Fsw {



/**

 * Returns the filename for use with filesystem functions

 */

static function setName ($file) {

if (DIRECTORY_SEPARATOR=="\\") {

$file=utf8_decode($file);

}

return $file;

}



/**

 * Encondes the filename returned by filesystem functions

 */

static function getName ($file) {

if (DIRECTORY_SEPARATOR=="\\") {

$file=utf8_encode($file);

}

return $file;

}





static function file_exists ($filename) {

return file_exists(self::setName($filename));

}



static function fopen ($filename,$mode) {

return fopen(self::setName($filename),$mode);

}



static function opendir ($dirname) {

return opendir(self::setName($dirname));

}



static function readdir ($dir_handle) {

$file=readdir($dir_handle);

if ($file) {

// check if file is found before converting it's

// name or we will convert bool(false) to string

$file=self::getName($file);

}

return $file;

}



// just create any other filesystem function you might use in your code
here



}


[2009-01-03 13:25:07] j...@php.net






[2009-01-02 08:06:39] alex dot bazan at concatel dot com

The UTF string did not get saved correctly in the bug report. It was a
japanese string.


[2009-01-02 08:03:37] alex dot bazan at concatel dot com

Description:

Under Windows, when I use fpoen() or mkdir() with a UTF8 encoded string,
the file or directory name is not converted to the filesystem encoding
and thus the file or directory is created with a wrong file name.

Reproduce code:
---


Expected result:

Directory 日本語 should be created

Actual result:
--
Directory 日本語 is created






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=46990&edit=1


Bug #47164 [Asn->Wfx]: uncomfortable (binary)char() append to binary string

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=47164&edit=1

 ID:   47164
 Updated by:   fel...@php.net
 Reported by:  lunter at interia dot pl
 Summary:  uncomfortable (binary)char() append to binary string
-Status:   Assigned
+Status:   Wont fix
 Type: Bug
 Package:  Unicode Engine related
 Operating System: *
 PHP Version:  6CVS-2009-01-20 (snap)
 Assigned To:  scottmac



Previous Comments:

[2009-01-21 16:24:57] johan...@php.net

Scott said he'd look into this :-)


[2009-01-21 12:31:14] lunter at interia dot pl

johan...@php.net "(binary)chr($c) will give the wrong result"



hmmm... try code above.



b1.dat consists utf-8 data

b2.dat consists binary chars 0 - 255 step 1, file length is correct -
256B & chars are correct...






[2009-01-21 11:26:24] johan...@php.net

$b = sprintf("%c%c%c", 255, 254, 253);



should work, but having a simple function might still be helpful


[2009-01-21 11:12:52] johan...@php.net

Actually we need a function doing "binary chr" - chr() in PHP 6 takes a
codepoint not the byte value, so  (binary)chr($c) will give the wrong
result.


[2009-01-20 10:59:03] lunter at interia dot pl

Description:

uncomfortable (binary)char() append to a binary string

Reproduce code:
---
$b=(binary)'';



$b.=chr(255);

$b.=chr(254);

$b.=chr(253);

$b.=chr(252);

$b.=chr(251);

...

$b.=chr(0);

Expected result:

detect $b type as binary string and adding chr() in binary mode



like this:



$b=(binary)'';



$b.=(binary)chr(255);

$b.=(binary)chr(254);

$b.=(binary)chr(253);

$b.=(binary)chr(252);

$b.=(binary)chr(251);

...

$b.=(binary)chr(0);

Actual result:
--
adding chr() in unicode






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=47164&edit=1


Bug #48240 [Asn->Csd]: DBA Segmentation fault dba_nextkey

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=48240&edit=1

 ID:   48240
 Updated by:   fel...@php.net
 Reported by:  VJTD3 at VJTD3 dot com
 Summary:  DBA Segmentation fault dba_nextkey
-Status:   Assigned
+Status:   Closed
 Type: Bug
 Package:  DBM/DBA related
 Operating System: linux redhat fedora 10
 PHP Version:  5.2.9
 Assigned To:  felipe

 New Comment:

The crash has been fixed, to change the behavior (when wasn't crashing)
lead to BC.


Previous Comments:

[2009-05-19 05:03:00] VJTD3 at VJTD3 dot com

i didn't see a reply, changed it to open in case that's needed for devs.


[2009-05-13 07:16:08] VJTD3 at VJTD3 dot com

can this be changed to return the first result if there is one and false
if there are none?



db_firstkey is a rewind, db_nextkey is a iterator. starting from the
beginning makes sense.


[2009-05-13 02:17:19] fel...@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.

Fixed in 5.2, 5.3 and HEAD.



FALSE is returned now.


[2009-05-12 14:31:58] VJTD3 at VJTD3 dot com

[New Thread 0xb7ff56c0 (LWP 10754)]



Program received signal SIGSEGV, Segmentation fault.

0x080d0c66 in dba_nextkey_db4 (info=0x84d75f0, newlen=0xbfffb360)

at php-5.2.9/ext/dba/dba_db4.c:222

222 if (dba->cursor->c_get(dba->cursor, &gkey, &gval,
DB_NEXT) == 0)  
   {

(gdb) bt

#0  0x080d0c66 in dba_nextkey_db4 (info=0x84d75f0, newlen=0xbfffb360)

at php-5.2.9/ext/dba/dba_db4.c:222

#1  0x080cf3cc in zif_dba_nextkey (ht=1, return_value=0x84d6e78,

return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)

at php-5.2.9/ext/dba/dba.c:1101

#2  0x08304280 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffb548)

at php-5.2.9/Zend/zend_vm_execute.h:200

#3  0x08309bba in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfffb548)

at php-5.2.9/Zend/zend_vm_execute.h:1729

#4  0x08303dfd in execute (op_array=0x84d7538)

at php-5.2.9/Zend/zend_vm_execute.h:92

#5  0x082df04e in zend_execute_scripts (type=8, retval=0x0,
file_count=3)

at php-5.2.9/Zend/zend.c:1134

#6  0x0828dd81 in php_execute_script (primary_file=0xbfffd8c4)

at php-5.2.9/main/main.c:2023

#7  0x0835a851 in main (argc=2, argv=0xbfffda04)

at php-5.2.9/sapi/cli/php_cli.c:1133

(gdb) frame 0

#0  0x080d0c66 in dba_nextkey_db4 (info=0x84d75f0, newlen=0xbfffb360)

at php-5.2.9/ext/dba/dba_db4.c:222

222 if (dba->cursor->c_get(dba->cursor, &gkey, &gval,
DB_NEXT) == 0)  
   {

(gdb) frame 1

#1  0x080cf3cc in zif_dba_nextkey (ht=1, return_value=0x84d6e78,

return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)

at php-5.2.9/ext/dba/dba.c:1101

1101nkey = info->hnd->nextkey(info, &len TSRMLS_CC);

(gdb) frame 2

#2  0x08304280 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffb548)

at php-5.2.9/Zend/zend_vm_execute.h:200

200 ((zend_internal_function *)
EX(function_state).f
unction)->handler(opline->extended_value,
EX_T(opline->result.u.var).var.ptr, EX  
 
(function_state).function->common.return_reference?&EX_T(opline->result.u.var).v

   ar.ptr:NULL, EX(object), return_value_used TSRMLS_CC);

(gdb) frame 3

#3  0x08309bba in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfffb548)

at php-5.2.9/Zend/zend_vm_execute.h:1729

1729return
zend_do_fcall_common_helper_SPEC(ZEND_OPCODE_HANDLER_ARGS   

_PASSTHRU);

(gdb) frame 4

#4  0x08303dfd in execute (op_array=0x84d7538)

at php-5.2.9/Zend/zend_vm_execute.h:92

92  if (EX(opline)->handler(&execute_data TSRMLS_CC)
> 0) {

(gdb) frame 5

#5  0x082df04e in zend_execute_scripts (type=8, retval=0x0,
file_count=3)

at php-5.2.9/Zend/zend.c:1134

1134zend_execute(EG(active_op_array)
TSRMLS_CC);

(gdb) frame 6

#6  0x0828dd81 in php_execute_script (primary_file=0xbfffd8c4)

at php-5.2.9/main/main.c:2023

2023retval = (zend_execute_scripts(ZEND_REQUIRE
TSRMLS_CC, N 

Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names

2010-06-13 Thread ceremcem at cshus dot org
Edit report at http://bugs.php.net/bug.php?id=18556&edit=1

 ID:   18556
 Comment by:   ceremcem at cshus dot org
 Reported by:  spud at nothingness dot org
 Summary:  Setting locale to 'tr_TR' lowercases class names
 Status:   Assigned
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: Linux (RedHat 7.2)
 PHP Version:  5CVS, 4CVS (2005-10-04)
 Assigned To:  dmitry

 New Comment:

This bug still exists in PHP version 5.3.2.


Previous Comments:

[2010-02-02 21:31:15] housecafe at freenet dot de

Dear php-team,



I´ve seen that 5.2.13RC1 is in progress. Could you fix this bug in this
version, please ?

Because I need turkish locale.



Thanks in advance.


[2010-01-22 09:00:27] paj...@php.net

Dmitry, can you look at it please? It is still reproduceable with 5.2
and 5.3.


[2009-11-13 16:58:15] joesiegrist at gmail dot com

It is unbelievable that this bug persists into 2009.  It is time to fix


it.


[2009-08-04 11:23:15] cankoy at ymail dot com

Setting LC_CTYPE to something other than tr_TR solves nothing, it's not
even a workaround, you just get a bastardized locale in which regex
patterns do not match Turkish char.s and XXlower/XXupper functions
become nothing but a joke.

This bug has been around for ages, so it's not fixable? OK, don't fix
it, but at least provide a means to turn off(*) the horrible PHP design
decision "case-insensitive function lookup", so that we have an option
to avoid all this mess.



(*)like, a Php.ini directive


[2009-07-30 17:21:41] onur dot oguzel at gmail dot com

i guess nobody looks at this bug, 

setlocale(LC_ALL, 'tr_TR');

setlocale(LC_CTYPE, 'en_US');



sure solves this but it is still a bug :)




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=18556


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=18556&edit=1


Bug #49764 [Asn->Fbk]: number_format() fails (randomly?)

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=49764&edit=1

 ID:   49764
 Updated by:   fel...@php.net
 Reported by:  tec at baufi24 dot de
 Summary:  number_format() fails (randomly?)
-Status:   Assigned
+Status:   Feedback
 Type: Bug
 Package:  Math related
 Operating System: Windows Server 2003 RC2
 PHP Version:  5.2.11
 Assigned To:  pajoye

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:

[2010-05-13 21:26:19] derek dot ethier at humber dot ca

I'm not sure if this will help at all, but outside of confirming this
issue with number_format, it now appears as though converting a string
to float causing a very similar problem.



It seems to happen so randomly, but the only consistent element is that
the numbers all have 9 in them.



There is an existing bug opened for float that was closed as bogus:

http://bugs.php.net/bug.php?id=47716


[2010-04-16 11:15:26] paj...@php.net

I will ask our test team to try to reproduce it.


[2010-04-15 20:24:54] derek dot ethier at humber dot ca

I've been experiencing a similar problem on 5.2.12 and 5.2.13 on a
Windows Server 2003 environment (not R2).



I haven't been able to nail down any sort of specifics as it happens so
randomly. The only consistent element seems to centre around odd numbers
(specifically with 9) format incorrectly in a similar manner to the one
originally described (with a colon in the middle).



I'm not sure if this helps at all, but I thought I'd add a comment
anyway.


[2009-12-21 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".


[2009-12-13 18:13:29] fel...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/






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=49764


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=49764&edit=1


Bug #49764 [Fbk->Asn]: number_format() fails (randomly?)

2010-06-13 Thread pajoye
Edit report at http://bugs.php.net/bug.php?id=49764&edit=1

 ID:   49764
 Updated by:   paj...@php.net
 Reported by:  tec at baufi24 dot de
 Summary:  number_format() fails (randomly?)
-Status:   Feedback
+Status:   Assigned
 Type: Bug
 Package:  Math related
 Operating System: Windows Server 2003 RC2
 PHP Version:  5.2.11
 Assigned To:  pajoye

 New Comment:

Nothing changed here.


Previous Comments:

[2010-06-13 19:26:12] fel...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




[2010-05-13 21:26:19] derek dot ethier at humber dot ca

I'm not sure if this will help at all, but outside of confirming this
issue with number_format, it now appears as though converting a string
to float causing a very similar problem.



It seems to happen so randomly, but the only consistent element is that
the numbers all have 9 in them.



There is an existing bug opened for float that was closed as bogus:

http://bugs.php.net/bug.php?id=47716


[2010-04-16 11:15:26] paj...@php.net

I will ask our test team to try to reproduce it.


[2010-04-15 20:24:54] derek dot ethier at humber dot ca

I've been experiencing a similar problem on 5.2.12 and 5.2.13 on a
Windows Server 2003 environment (not R2).



I haven't been able to nail down any sort of specifics as it happens so
randomly. The only consistent element seems to centre around odd numbers
(specifically with 9) format incorrectly in a similar manner to the one
originally described (with a colon in the middle).



I'm not sure if this helps at all, but I thought I'd add a comment
anyway.


[2009-12-21 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".




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=49764


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=49764&edit=1


Bug #51920 [Com]: ip2long result depends on platform

2010-06-13 Thread artificial at iol dot ie
Edit report at http://bugs.php.net/bug.php?id=51920&edit=1

 ID:   51920
 Comment by:   artificial at iol dot ie
 Reported by:  olafvdspek at gmail dot com
 Summary:  ip2long result depends on platform
 Status:   Bogus
 Type: Bug
 Package:  Network related
 Operating System: Debian x64
 PHP Version:  5.3.2

 New Comment:

This is why I peruse bugs.php.net... for the lulz when somebody submits
a bogus bug and makes themself look stupid.


Previous Comments:

[2010-05-27 09:41:35] olafvdspek at gmail dot com

Like I said before, I know what signed and unsigned shorts, ints, longs
and long longs are.


[2010-05-27 08:25:49] m...@php.net

Please read up on that topic and stop complaining about nothing.

You may start here or anywhere else:

http://en.wikipedia.org/wiki/Integer_%28computer_science%29


[2010-05-26 23:28:15] olafvdspek at gmail dot com

Then just return the negative value.


[2010-05-26 23:26:23] johan...@php.net

This would be a different binary representation, which breaks binary
math, which people often do with IP addresses.


[2010-05-26 17:16:53] olafvdspek at gmail dot com

Returning -107373295 on x64 would make it consistent with x86.



But people might prefer 3221234342, in which case it could be returned
as a string.




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=51920


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51920&edit=1


Bug #50858 [Asn->Csd]: $encryption_key parameter seems to be ineffective

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=50858&edit=1

 ID:   50858
 Updated by:   fel...@php.net
 Reported by:  roger dot olivier at gmail dot com
 Summary:  $encryption_key parameter seems to be ineffective
-Status:   Assigned
+Status:   Closed
 Type: Bug
 Package:  SQLite related
 Operating System: win32 only - Windows XP Sp3
 PHP Version:  5.3.1
 Assigned To:  scottmac

 New Comment:

The encryption_key will be used if the SQLITE_HAS_CODEC was properly
defined in the build.


Previous Comments:

[2010-01-27 10:12:05] roger dot olivier at gmail dot com

Description:

The use of the encryption_key parameter in the SQLite3::open method
don't works whereas the sqlite3 extension is compiled with the support
of SEE (http://www.hwaci.com/sw/sqlite/see.html)



The extension as been compiled in VC9 with the following configure : 

configure --enable-apache2-2handler --with-sqlite3=shared
--enable-pdo=shared --with-pdo-sqlite=shared --enable-cgi
--without-t1lib --enable-cli-win32
--with-extra-includes=d:/projets/php-sdk/Apache2/include;d:/projets/php-sdk/icu/include
--with-extra-libs=d:/projets/php-sdk/Apache2/lib;d:/projets/php-sdk/icu/



The new php_sqlite3.dll and php_pdo_sqlite.dll are used to replace the
dll present in the binary (still 5.3.1 VC9).



Note : The use of PRAGMA key = 'mykey' works fine , it's just the use of
the encryption_key parameter which seems broken

Reproduce code:
---
query('SELECT COUNT(*) from users');

var_dump($result->fetchArray());

?>

Expected result:

array(2) { [0]=>  int(1) ["COUNT(*)"]=>  int(1) } 

Actual result:
--
Unable to prepare statement: 26, file is encrypted or is not a database
in






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50858&edit=1


Bug #50858 [Csd->Bgs]: $encryption_key parameter seems to be ineffective

2010-06-13 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=50858&edit=1

 ID:   50858
 Updated by:   fel...@php.net
 Reported by:  roger dot olivier at gmail dot com
 Summary:  $encryption_key parameter seems to be ineffective
-Status:   Closed
+Status:   Bogus
 Type: Bug
 Package:  SQLite related
 Operating System: win32 only - Windows XP Sp3
 PHP Version:  5.3.1
 Assigned To:  scottmac



Previous Comments:

[2010-06-13 20:04:29] fel...@php.net

The encryption_key will be used if the SQLITE_HAS_CODEC was properly
defined in the build.


[2010-01-27 10:12:05] roger dot olivier at gmail dot com

Description:

The use of the encryption_key parameter in the SQLite3::open method
don't works whereas the sqlite3 extension is compiled with the support
of SEE (http://www.hwaci.com/sw/sqlite/see.html)



The extension as been compiled in VC9 with the following configure : 

configure --enable-apache2-2handler --with-sqlite3=shared
--enable-pdo=shared --with-pdo-sqlite=shared --enable-cgi
--without-t1lib --enable-cli-win32
--with-extra-includes=d:/projets/php-sdk/Apache2/include;d:/projets/php-sdk/icu/include
--with-extra-libs=d:/projets/php-sdk/Apache2/lib;d:/projets/php-sdk/icu/



The new php_sqlite3.dll and php_pdo_sqlite.dll are used to replace the
dll present in the binary (still 5.3.1 VC9).



Note : The use of PRAGMA key = 'mykey' works fine , it's just the use of
the encryption_key parameter which seems broken

Reproduce code:
---
query('SELECT COUNT(*) from users');

var_dump($result->fetchArray());

?>

Expected result:

array(2) { [0]=>  int(1) ["COUNT(*)"]=>  int(1) } 

Actual result:
--
Unable to prepare statement: 26, file is encrypted or is not a database
in






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50858&edit=1


Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names

2010-06-13 Thread ceremcem at cshus dot org
Edit report at http://bugs.php.net/bug.php?id=18556&edit=1

 ID:   18556
 Comment by:   ceremcem at cshus dot org
 Reported by:  spud at nothingness dot org
 Summary:  Setting locale to 'tr_TR' lowercases class names
 Status:   Assigned
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: Linux (RedHat 7.2)
 PHP Version:  5CVS, 4CVS (2005-10-04)
 Assigned To:  dmitry

 New Comment:

EDIT: The code that I used to regenerate this bug as follows: 



foreach(get_declared_classes() as $class)

{

 if(!class_exists($class))

 echo "$class No Longer Exists!\n";

}



This code does not produce errors anymore but method names are still
giving this type of error. 



I'm using ImageMagick and its PHP extension, imagick, which gives the
error "fatal: thumbnailImage() method not found", seems to be related
with this bug. When I rewrite the method name as ...->thumbnailimage(),
all works OK. 



So, the methods documented in
http://www.php.net/manual/en/class.imagick.php which include "I"
(capital i), it can not be used without replacing "I" with "i". (same
errors occur with MagickWand class)



Could you please fix this too?


Previous Comments:

[2010-06-13 19:11:23] ceremcem at cshus dot org

This bug still exists in PHP version 5.3.2.


[2010-02-02 21:31:15] housecafe at freenet dot de

Dear php-team,



I´ve seen that 5.2.13RC1 is in progress. Could you fix this bug in this
version, please ?

Because I need turkish locale.



Thanks in advance.


[2010-01-22 09:00:27] paj...@php.net

Dmitry, can you look at it please? It is still reproduceable with 5.2
and 5.3.


[2009-11-13 16:58:15] joesiegrist at gmail dot com

It is unbelievable that this bug persists into 2009.  It is time to fix


it.


[2009-08-04 11:23:15] cankoy at ymail dot com

Setting LC_CTYPE to something other than tr_TR solves nothing, it's not
even a workaround, you just get a bastardized locale in which regex
patterns do not match Turkish char.s and XXlower/XXupper functions
become nothing but a joke.

This bug has been around for ages, so it's not fixable? OK, don't fix
it, but at least provide a means to turn off(*) the horrible PHP design
decision "case-insensitive function lookup", so that we have an option
to avoid all this mess.



(*)like, a Php.ini directive




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=18556


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=18556&edit=1


Bug #50374 [Asn]: .user.ini subdirectory not working and problem with [PATH] in php.ini

2010-06-13 Thread tom_borgo at hotmail dot com
Edit report at http://bugs.php.net/bug.php?id=50374&edit=1

 ID:   50374
 User updated by:  tom_borgo at hotmail dot com
 Reported by:  tom_borgo at hotmail dot com
 Summary:  .user.ini subdirectory not working and problem with
   [PATH] in php.ini
 Status:   Assigned
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: XP SP3
 PHP Version:  5.3.1
 Assigned To:  pajoye

 New Comment:

Hello,



Yes, the problem has not been resolved, or the documentation has not
been updated to say that it is normal that it doesn't affect the
subdirectory.

It is a shame because .user.ini is very important to use php directive
by directory (because htaccess cannot be used in this way like PHP in
apache module).



I hope problem will be taken really into consideration. And it is really
easy to test it.



Thanks.

Thomas.


Previous Comments:

[2010-06-10 21:15:49] jirka at pbox dot cz

Same issue with php 5.3.2 (CGI) on WinXP SP3. Build date Apr 1 2010
17:13:20.

.user.ini custom setting works in the directory where the ini file is
located, but 

has no effect in any of subdirectories.


[2009-12-11 01:00:00] 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".


[2009-12-03 16:10:27] tom_borgo at hotmail dot com

Ok so i just tried with the 5.3.2-dev (Dec 3 2009 14:57:19) snapshot.



Problem .user.ini for php script in subdirectory is always the same.

/www/phpinfo.php -> take into account the /www/.user.ini

/www/administrator/phpinfo.php -> take NOT into account the
/www/.user.ini



For the [PATH] problem, i tried and problem is no more here.

So I tried again with 5.3.1, no more problem.

Problem is just with 5.3.0 (VC8 from ZendServer), so [PATH] problem is
just for ZendServer.

So we can forgot about the [PATH] problem.



But for the .user.ini, am i mistaken something ? Or is it a php problem
?



Thanks.

Thomas.


[2009-12-03 15:50:05] tom_borgo at hotmail dot com

To:  paj...@php.net



Yes I know it works only for CGI/FastCGI SAPI
(http://php.net/manual/en/configuration.file.per-user.php).

.user.ini works for me only for the directory where it is and without
any [PATH] section in the main php.ini.



I tried with a PHP downloaded from the php.net (5.3.1 NTS VC6 and i try
with VC9 too). It is the same as the one from ZendServer (VC8).

So problem is in ZendServer,but too in the last stable binary windows
compiled on the php.net website.



Is it a configuration problem on my side or does another people got the
same problems ?



I will try with the snapshot right now.

I keep you warning.

Thanks.

Thomas.


[2009-12-03 15:39:18] tom_borgo at hotmail dot com

Just a comment about the [PATH] section

It is said in http://php.net/ini.sections that directive in PATH section
overide custom and runtime ini directives. So I think it is in fact
normal that .user.ini don't change the display_errors flag.

But .user.ini are not parsed if [PATH] section are in the main php.ini
for other directory



Ex:

[PATH=/www2/]

display_errors = 1



/www/.user.ini is not more taken into account !

If i remove the PATH section (i put it inthe end of my php.ini),
.user.ini is taken into account.

Really strange...




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=50374


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50374&edit=1


Bug #50374 [Asn]: .user.ini subdirectory not working and problem with [PATH] in php.ini

2010-06-13 Thread pajoye
Edit report at http://bugs.php.net/bug.php?id=50374&edit=1

 ID:   50374
 Updated by:   paj...@php.net
 Reported by:  tom_borgo at hotmail dot com
 Summary:  .user.ini subdirectory not working and problem with
   [PATH] in php.ini
 Status:   Assigned
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: XP SP3
 PHP Version:  5.3.1
 Assigned To:  pajoye

 New Comment:

Assigned means "someone (me) will work on it", not "it is fixed" :)



Btw, htscanner allows htaccess-like file for 5.x, for the record.


Previous Comments:

[2010-06-13 20:19:49] tom_borgo at hotmail dot com

Hello,



Yes, the problem has not been resolved, or the documentation has not
been updated to say that it is normal that it doesn't affect the
subdirectory.

It is a shame because .user.ini is very important to use php directive
by directory (because htaccess cannot be used in this way like PHP in
apache module).



I hope problem will be taken really into consideration. And it is really
easy to test it.



Thanks.

Thomas.


[2010-06-10 21:15:49] jirka at pbox dot cz

Same issue with php 5.3.2 (CGI) on WinXP SP3. Build date Apr 1 2010
17:13:20.

.user.ini custom setting works in the directory where the ini file is
located, but 

has no effect in any of subdirectories.


[2009-12-11 01:00:00] 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".


[2009-12-03 16:10:27] tom_borgo at hotmail dot com

Ok so i just tried with the 5.3.2-dev (Dec 3 2009 14:57:19) snapshot.



Problem .user.ini for php script in subdirectory is always the same.

/www/phpinfo.php -> take into account the /www/.user.ini

/www/administrator/phpinfo.php -> take NOT into account the
/www/.user.ini



For the [PATH] problem, i tried and problem is no more here.

So I tried again with 5.3.1, no more problem.

Problem is just with 5.3.0 (VC8 from ZendServer), so [PATH] problem is
just for ZendServer.

So we can forgot about the [PATH] problem.



But for the .user.ini, am i mistaken something ? Or is it a php problem
?



Thanks.

Thomas.


[2009-12-03 15:50:05] tom_borgo at hotmail dot com

To:  paj...@php.net



Yes I know it works only for CGI/FastCGI SAPI
(http://php.net/manual/en/configuration.file.per-user.php).

.user.ini works for me only for the directory where it is and without
any [PATH] section in the main php.ini.



I tried with a PHP downloaded from the php.net (5.3.1 NTS VC6 and i try
with VC9 too). It is the same as the one from ZendServer (VC8).

So problem is in ZendServer,but too in the last stable binary windows
compiled on the php.net website.



Is it a configuration problem on my side or does another people got the
same problems ?



I will try with the snapshot right now.

I keep you warning.

Thanks.

Thomas.




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=50374


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50374&edit=1


Bug #50374 [Asn]: .user.ini subdirectory not working and problem with [PATH] in php.ini

2010-06-13 Thread tom_borgo at hotmail dot com
Edit report at http://bugs.php.net/bug.php?id=50374&edit=1

 ID:   50374
 User updated by:  tom_borgo at hotmail dot com
 Reported by:  tom_borgo at hotmail dot com
 Summary:  .user.ini subdirectory not working and problem with
   [PATH] in php.ini
 Status:   Assigned
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: XP SP3
 PHP Version:  5.3.1
 Assigned To:  pajoye

 New Comment:

Thanks Pajoye for your fast answer.

I really hope you can fix it ! :)



Yes htscanner is an alternative solution, i never try it. I prefer rely
on PHP itself. And htscanner is in alpha stage and last release is more
one year old, i mean for system in real production it is necessary to
have stable version. Htscanner seems ok for leisure purpose but I will
not use it for bussiness application.


Previous Comments:

[2010-06-13 20:32:37] paj...@php.net

Assigned means "someone (me) will work on it", not "it is fixed" :)



Btw, htscanner allows htaccess-like file for 5.x, for the record.


[2010-06-13 20:19:49] tom_borgo at hotmail dot com

Hello,



Yes, the problem has not been resolved, or the documentation has not
been updated to say that it is normal that it doesn't affect the
subdirectory.

It is a shame because .user.ini is very important to use php directive
by directory (because htaccess cannot be used in this way like PHP in
apache module).



I hope problem will be taken really into consideration. And it is really
easy to test it.



Thanks.

Thomas.


[2010-06-10 21:15:49] jirka at pbox dot cz

Same issue with php 5.3.2 (CGI) on WinXP SP3. Build date Apr 1 2010
17:13:20.

.user.ini custom setting works in the directory where the ini file is
located, but 

has no effect in any of subdirectories.


[2009-12-11 01:00:00] 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".


[2009-12-03 16:10:27] tom_borgo at hotmail dot com

Ok so i just tried with the 5.3.2-dev (Dec 3 2009 14:57:19) snapshot.



Problem .user.ini for php script in subdirectory is always the same.

/www/phpinfo.php -> take into account the /www/.user.ini

/www/administrator/phpinfo.php -> take NOT into account the
/www/.user.ini



For the [PATH] problem, i tried and problem is no more here.

So I tried again with 5.3.1, no more problem.

Problem is just with 5.3.0 (VC8 from ZendServer), so [PATH] problem is
just for ZendServer.

So we can forgot about the [PATH] problem.



But for the .user.ini, am i mistaken something ? Or is it a php problem
?



Thanks.

Thomas.




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=50374


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50374&edit=1


[PHP-BUG] Req #52076 [NEW]: rename Australian time zone abbreviations to avoid ambiguity

2010-06-13 Thread dfsdf at mailinator dot com
From: 
Operating system: Linux
PHP version:  5.3.2
Package:  Date/time related
Bug Type: Feature/Change Request
Bug description:rename Australian time zone abbreviations to avoid ambiguity

Description:

In PHP, formatting a date with 'T' for an Australian East or Central time
zone generates "EST" and "CST" respectively. Since time zone calculations
often involve global context, it is confusing to have multiple definitions
of EST and CST, as EST is also used for Eastern Standard Time (US) and CST
for Central Standard Time (US).



To quote Wikipedia:



"The proper names of Australia's time zones vary. In international contexts
they are often called Australian Western Standard Time (AWST), Australian
Central Standard Time (ACST), and Australian Eastern Standard Time (AEST).
In domestic contexts the leading "Australian" is often dropped."


-- 
Edit bug report at http://bugs.php.net/bug.php?id=52076&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52076&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52076&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=52076&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52076&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=52076&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52076&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=52076&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=52076&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=52076&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=52076&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=52076&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=52076&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=52076&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52076&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=52076&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52076&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=52076&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=52076&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=52076&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=52076&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=52076&r=mysqlcfg



Req #52076 [Opn->Wfx]: rename Australian time zone abbreviations to avoid ambiguity

2010-06-13 Thread derick
Edit report at http://bugs.php.net/bug.php?id=52076&edit=1

 ID:   52076
 Updated by:   der...@php.net
 Reported by:  dfsdf at mailinator dot com
 Summary:  rename Australian time zone abbreviations to avoid
   ambiguity
-Status:   Open
+Status:   Wont fix
 Type: Feature/Change Request
 Package:  Date/time related
 Operating System: Linux
 PHP Version:  5.3.2

 New Comment:

We are consuming another data source here. If you want to get this
changed, you need to take this up with the folks at
http://www.twinsun.com/tz/tz-link.htm through their mailing-list. I can
however tell you, that you probably have little success convincing them
without proper backed-up governmental descriptions.


Previous Comments:

[2010-06-13 21:14:09] dfsdf at mailinator dot com

Description:

In PHP, formatting a date with 'T' for an Australian East or Central
time zone generates "EST" and "CST" respectively. Since time zone
calculations often involve global context, it is confusing to have
multiple definitions of EST and CST, as EST is also used for Eastern
Standard Time (US) and CST for Central Standard Time (US).



To quote Wikipedia:



"The proper names of Australia's time zones vary. In international
contexts they are often called Australian Western Standard Time (AWST),
Australian Central Standard Time (ACST), and Australian Eastern Standard
Time (AEST). In domestic contexts the leading "Australian" is often
dropped."







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52076&edit=1


[PHP-BUG] Bug #52077 [NEW]: SNMP GET/WALK may hangs FOREVER

2010-06-13 Thread wajim at mail dot ru
From: 
Operating system: Win XP SP3
PHP version:  5.2.13
Package:  SNMP related
Bug Type: Bug
Bug description:SNMP GET/WALK may hangs FOREVER

Description:

Under a heavy GET/WALK-ing (form localhost to localhost) php may hangs
forever -> apache's threads becomes zombies with CLOSE_WAIT sates even all
timeouts (php and apache) are elapsed many times.



Call-stack of a one zombie-thread:

ntoskrnl.exe!KiUnlockDispatcherDatabase+0x77

ntoskrnl.exe!KeSetEvent+0x74

ntoskrnl.exe!PspGetSetContextSpecialApc+0x4e

ntoskrnl.exe!KiDeliverApc+0xb3

ntoskrnl.exe!KiSwapThread+0x64

ntoskrnl.exe!KeWaitForSingleObject+0x1c2

ntoskrnl.exe!NtWaitForSingleObject+0x9a

ntoskrnl.exe!KiFastCallEntry+0xf8

ntdll.dll!KiFastSystemCallRet

ntdll.dll!ZwWaitForSingleObject+0xc

mswsock.dll!SockWaitForSingleObject+0x1a0

mswsock.dll!WSPRecvFrom+0x1f0

WS2_32.dll!recvfrom+0x89

php_snmp.dll!snmp_sess_read+0x21f

php_snmp.dll!snmp_sess_read+0x10

php_snmp.dll!snmp_read+0x17

php_snmp.dll!snmp_synch_response_cb+0xe8

php_snmp.dll!snmp_synch_response+0x19

php_snmp.dll!php_snmp_internal+0x267

php_snmp.dll!php_snmp+0x6da

php_snmp.dll!zif_snmp2_get+0x27

php5ts.dll!zend_do_fcall_common_helper_SPEC+0x7ab

php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER+0xe5

php5ts.dll!execute+0x1c5

php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca

php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15

php5ts.dll!execute+0x1c5

php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca

php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15

php5ts.dll!execute+0x1c5

php5ts.dll!zend_execute_scripts+0x107

php5ts.dll!php_execute_script+0x21d

php5apache.dll!apache_php_module_main+0x91

php5apache.dll!send_php+0x265

php5apache.dll!send_parsed_php+0x10

ApacheCore.dll!ap_invoke_handler+0x87

ApacheCore.dll!ap_process_request+0x2b4

ApacheCore.dll!ap_process_request+0x26

ApacheCore.dll!ap_start_restart+0x37f

WS2_32.dll!WSASocketW+0x119



IMHO bad call "WS2_32.dll!recvfrom" in buggy ucd-snmp library may hangs.
There are no socket option like "setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO,
..." before recvfrom call.


-- 
Edit bug report at http://bugs.php.net/bug.php?id=52077&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52077&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52077&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=52077&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52077&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=52077&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52077&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=52077&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=52077&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=52077&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=52077&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=52077&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=52077&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=52077&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52077&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=52077&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52077&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=52077&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=52077&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=52077&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=52077&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=52077&r=mysqlcfg



[PHP-BUG] Bug #52078 [NEW]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt

2010-06-13 Thread glen at delfi dot ee
From: 
Operating system: PLD Linux
PHP version:  5.3.2
Package:  *General Issues
Bug Type: Bug
Bug description:fileinode overflow test 
ext/standard/tests/file/fileinode_variation3.phpt

Description:

fileinode overflows on filesystem where inode count is huge.



it is mentioned in comment of manual as well:

http://php.net/manual/en/function.fileinode.php



Test script:
---
$ (t=`mktemp -d`; cd $t; php -r 'var_dump(fileinode("."));'; echo $t; ls
-ldi $t)

int(-2051936757)



/home/users/glen/tmp/tmp.zLdoithBR0



2243030539 drwx-- 2 glen users 6 Jun 14 00:26
/home/users/glen/tmp/tmp.zLdoithBR0/



Expected result:

test must be fixed to expect %i instead of %d.


-- 
Edit bug report at http://bugs.php.net/bug.php?id=52078&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52078&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52078&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=52078&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52078&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=52078&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52078&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=52078&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=52078&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=52078&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=52078&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=52078&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=52078&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=52078&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52078&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=52078&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52078&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=52078&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=52078&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=52078&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=52078&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=52078&r=mysqlcfg



Bug #52078 [Opn]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt

2010-06-13 Thread glen at delfi dot ee
Edit report at http://bugs.php.net/bug.php?id=52078&edit=1

 ID:   52078
 User updated by:  glen at delfi dot ee
 Reported by:  glen at delfi dot ee
 Summary:  fileinode overflow test
   ext/standard/tests/file/fileinode_variation3.phpt
 Status:   Open
 Type: Bug
-Package:  *General Issues
+Package:  Filesystem function related
 Operating System: PLD Linux
 PHP Version:  5.3.2

 New Comment:

fix package


Previous Comments:

[2010-06-13 23:29:48] glen at delfi dot ee

Description:

fileinode overflows on filesystem where inode count is huge.



it is mentioned in comment of manual as well:

http://php.net/manual/en/function.fileinode.php



Test script:
---
$ (t=`mktemp -d`; cd $t; php -r 'var_dump(fileinode("."));'; echo $t; ls
-ldi $t)

int(-2051936757)



/home/users/glen/tmp/tmp.zLdoithBR0



2243030539 drwx-- 2 glen users 6 Jun 14 00:26
/home/users/glen/tmp/tmp.zLdoithBR0/



Expected result:

test must be fixed to expect %i instead of %d.







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52078&edit=1


Bug #31481 [Com]: curl isn't following redirects with a relative path

2010-06-13 Thread ktcox at rogers dot com
Edit report at http://bugs.php.net/bug.php?id=31481&edit=1

 ID:   31481
 Comment by:   ktcox at rogers dot com
 Reported by:  jason at merchant dot to
 Summary:  curl isn't following redirects with a relative path
 Status:   No Feedback
 Type: Bug
 Package:  HTTP related
 Operating System: Windows XP Pro
 PHP Version:  4.3.10

 New Comment:

This Works

http://localhost/updateindex.php');   


$page = curl_exec($addpage);

curl_close($addpage);

echo "$page";

?>



The following don't work.














Previous Comments:

[2005-01-31 22:34:22] sni...@php.net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.




[2005-01-11 04:54:37] sni...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.




[2005-01-11 00:07:59] jason at merchant dot to

Description:

I am grabbing an https:// page using curl and that page redirects using
a relative path like "/page1.php". curl is failing to follow this path.
I have tried replacing the relative path with an absolute path on the
page I'm grabbing and that worked so I know the problem lies in the
relative path redirection.







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=31481&edit=1


Bug #52018 [Com]: Probable cookie problem with 5.3.2

2010-06-13 Thread dklanac at gmail dot com
Edit report at http://bugs.php.net/bug.php?id=52018&edit=1

 ID:   52018
 Comment by:   dklanac at gmail dot com
 Reported by:  nospam at nospam dot homelinux dot org
 Summary:  Probable cookie problem with 5.3.2
 Status:   Open
 Type: Bug
 Package:  HTTP related
 Operating System: Linux Debian 5.0.4
 PHP Version:  5.3.2

 New Comment:

Correction.  My local PHP version whose cookies work properly is 5.3.1.


Previous Comments:

[2010-06-08 13:05:33] nospam at nospam dot homelinux dot org

Isolating the phpBB "automatic logon" feature would likely be a long and
complex task, as I haven't deeply studied its code.

I already opened a topic on the phpBB forum about 10 days ago, I just
added an update to it.

http://www.phpbb.com/community/viewtopic.php?t=2092537



Gingko


[2010-06-08 07:54:26] phi...@php.net

Maybe you can reproduce by isolating the phpBB "automatic logon"
feature? Do the 

phpBB people have any ideas? I suspect they'd do a more efficient job
finding this 

bug.


[2010-06-07 21:47:59] nospam at nospam dot homelinux dot org

Description:

There seems to be a problem with PHP 5.3.2: cookies are not working
properly in some cases, for example when running PhpBB 3.0.5 (and
probably other versions also).



The reason **seems** to be that the $_COOKIE super global variable is
not always populated with received cookies, and the most visible effect
is that the users of my phpBB forum are not able to use the “automatic
logon” feature of phpBB.



However, a simple test case with the setcookie function works properly,
so I don’t know exactly what kind of cookie can trigger the bug.



Downgrading to phpBB 5.2.13 or lower effectively fix the problem.



I made multiple tries, using either 5.2.6, 5.2.13 or 5.3.2, either
compiled by myself or installed from Debian packages, with or without
the Debian security patches, while keeping the same php.ini
configuration in all cases, and the result was always the same:

- with 5.2.6 or 5.2.13, cookies are handled properly, and phpBB users
can use the phpBB's automatic “automatic logon” feature.

- with 5.3.2, cookies seem to be blocked, $_COOKIE is not populated
(except maybe by as many empty strings as the number of expected
cookies).



The server also uses Apache 2.2.9 and MySQL 5.1.46, and I tried on two
different Debian 5.0.4 configurations, one as 32 bits at my home and one
as 64 bits in a datacenter.



I used Wireshark for network sniffing, so I can tell that cookies are
truely present in HTTP headers.



I tracked the $_COOKIE variable by adding a "error_log(print_r($_COOKIE,
true))" instruction near the beginning of the phpBB common code.

Test script:
---
I'm sorry, I don't know how to make a short test script showing the
problem. I tried a short test with setcookie but it worked properly,
even with 5.3.2. I suppose that there are some combined interactions
within phpBB triggering this problem when they happen altogether.



The only procedure that I can suggest is the following:



- Install a phpBB server (download from http://www.php.net/) with the
default configuration.

- Create a user account with any name.

- Try to login on this account. Don't forget to check the "Log me on
automatically each visit" option when login.

- Browse a little inside the forum, check that the connexion is kept by
session ID.

- Quit your browser, closing all of its Windows.

- Reopen the browser, and open again the phpBB forum. Use the root
address of the forum, without the session ID parameter.



Expected result:

When opening the forum homepage, login should be already made, kept from
previous session.

This is what happens with 5.2.6 or 5.2.13.



Actual result:
--
Forum open correctly, but previous login is completely forgotten.

This is what happens with 5.3.2.






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52018&edit=1


Bug #31481 [NoF]: curl isn't following redirects with a relative path

2010-06-13 Thread rasmus
Edit report at http://bugs.php.net/bug.php?id=31481&edit=1

 ID:   31481
 Updated by:   ras...@php.net
 Reported by:  jason at merchant dot to
 Summary:  curl isn't following redirects with a relative path
 Status:   No Feedback
 Type: Bug
 Package:  HTTP related
 Operating System: Windows XP Pro
 PHP Version:  4.3.10

 New Comment:

Those are not supposed to work.  curl_init() takes a URL.  None of the
arguments 

in your example that don't work are URLs.


Previous Comments:

[2010-06-14 00:15:42] ktcox at rogers dot com

This Works

http://localhost/updateindex.php');   


$page = curl_exec($addpage);

curl_close($addpage);

echo "$page";

?>



The following don't work.














[2005-01-31 22:34:22] sni...@php.net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.




[2005-01-11 04:54:37] sni...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.




[2005-01-11 00:07:59] jason at merchant dot to

Description:

I am grabbing an https:// page using curl and that page redirects using
a relative path like "/page1.php". curl is failing to follow this path.
I have tried replacing the relative path with an absolute path on the
page I'm grabbing and that worked so I know the problem lies in the
relative path redirection.







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=31481&edit=1