Bug #48966 [Com]: namespace in soap headers not put into nested tags

2010-12-17 Thread james dot roger dot ward at gmail dot com 
Edit report at http://bugs.php.net/bug.php?id=48966&edit=1

 ID: 48966
 Comment by: james dot roger dot ward at gmail dot com
 Reported by:moographics at gmail dot com
 Summary:namespace in soap headers not put into nested tags
 Status: Open
 Type:   Bug
 Package:SOAP related
 Operating System:   OSX
 PHP Version:5.2.10
 Block user comment: N
 Private report: N

 New Comment:

I've a similar problem in PHP 5.3.3 on OSX and believe that its root
cause is the same, thus the add-on comment to this bug rather than
filing a new one.



Reproduce code:

---

http://soap.m4u.com.au/?wsdl";,

  array ("trace" => 1, "exceptions" => 1)) ;



$auth -> userId = "ABC" ;

$auth -> password = "DEF" ;

$arg -> authentication = $auth ;



try {

$response = $client -> checkUser ($arg) ;



} catch (SoapFault $e) {

  echo "\nEXCEPTION:\n".$e;

  echo "\n\nREQUEST WAS:\n";

  echo $client -> __getLastRequest () ;

  exit ;

  }

?> 



The namespace prefix is missing from the XML generated to represent the
two scalars in the "authentication" object, "userID" and "password". 
Here's the actual message content, rejected by the server:



http://schemas.xmlsoap.org/soap/envelope/";

 xmlns:ns1="http://xml.m4u.com.au/2009";>

  



  

ABC

DEF

  



  





Here's the expected content:



http://schemas.xmlsoap.org/soap/envelope/";

 xmlns:ns1="http://xml.m4u.com.au/2009";>

  



  

ABC

DEF

  



  




Previous Comments:

[2009-07-18 07:40:55] moographics at gmail dot com

Description:

This has been reported before #40318 and marked as bogus but it is not 

bogus - it simply fails to work as expected.

When using soap classes the generated xml header does not have the 

namespace prefix for all the tags.

When creating a soap header the soapVar is passed. The xml that is 

generated has the correct namespace prefix for the outer tag that is 

generated but the inner tags have no prefix. Bug #40318 suggests that 

the namespace cannot be guessed for the inner tags. I am suggesting that


the namespace for the inner tags surely can be assumed from the outer 

tags namespace. The suggested workaround did not work for me. My 

workaround was to roll my own xml.

Reproduce code:
---
class AuthHeader {

private $UsernameToken;

public function __construct($username,$password) {

$this->UsernameToken = new AuthDetails($username,$password);

}

}

class AuthDetails {

private $Username;

private $Password;

public function __construct($username,$password) {

$this->Username = $username;

$this->Password = $password;

}

}

$auth = new AuthHeader('xxx','xxx');

$security_ns = 'http://namespace';

$authvalues = new SoapVar($auth, SOAP_ENC_OBJECT);

$header = new SoapHeader($security_ns, 'Security', $authvalues);



Expected result:



http://schemas.xmlsoap.org/soap/envelope/"; 

xmlns:ns1="http://namespace1.xsd"; xmlns:ns2="http://namespace2.xsd";>







xxx'

xxx











courseList

review

courseList

2009-07-18T17:28:40

XXX







Actual result:
--


http://schemas.xmlsoap.org/soap/envelope/"; 

xmlns:ns1="http://namespace1.xsd"; xmlns:ns2="http://namespace2.xsd";>







XXX'

XXX











courseList

review

courseList

2009-07-18T17:28:40

XXX












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

#50858 [NEW]: $encryption_key parameter seems to be ineffective

2010-01-27 Thread roger dot olivier at gmail dot com 
From: roger dot olivier at gmail dot com
Operating system: Windows XP Sp3
PHP version:  5.3.1
PHP Bug Type: SQLite related
Bug description:  $encryption_key parameter seems to be ineffective

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 bug report at http://bugs.php.net/?id=50858&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50858&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50858&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50858&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50858&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=50858&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50858&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=50858&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=50858&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=50858&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=50858&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=50858&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=50858&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=50858&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50858&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=50858&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50858&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=50858&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=50858&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=50858&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=50858&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=50858&r=mysqlcfg

#49349 [Com]: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors)

2009-10-14 Thread roger dot olivier at gmail dot com 
 ID:   49349
 Comment by:   roger dot olivier at gmail dot com
 Reported By:  raulsalitrero at gmail dot com
 Status:   No Feedback
 Bug Type: Gettext related
 Operating System: win32 only - windows xp sp3
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

As asked by paj...@php.net you can found here an archive with a working
script with 5.2.5 and not with 5.3.0
Tested on Xp pro Sp3

http://www.lanforums.com/dl/gettext-setlocale_BUG_5.3.0.zip

Unzip and launch index.php.
Expected result => print "Hello world" on screen
Actual result =>   print "bonjour le monde" on screen


Previous Comments:


[2009-10-02 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-09-24 18:05:55] paj...@php.net

Yes, but nobody managed to get to it at this stage. I assign it to me
so I won't forget to check this problem.

To ease my work it would be nice if someone can zip a working script
with 5.2, with mo/po files, where it should be placed, etc. and
describe. That will shorten the time I will have to spend on the issue.



[2009-09-24 16:51:48] bkraul at yahoo dot com

I was wondering this this issue is expected to be resolved in the near
future? Right know I have gotten around it by reverting back to php
5.2.11. Is this a problem with the extension itself?

Regards,

Belman Kraul



[2009-09-09 12:55:57] ameoba32 at gmail dot com

On windows vista sp2 + php-5.3.0-Win32-VC9-x86 

gettext function always searches for "en_US" or "en" path in locale
directory.

PHP 5.2.3 is okay.

this code produces different results



In php 5.3.0 it does not translate.



[2009-08-24 16:49:49] raulsalitrero at gmail dot com

Description:

usign gettext functions under php 5.3.0 (built with vc9) works
differently to how it used to work in php 5.2.x (tested on 5.2.10 built
with vc6).

it used to work even after a setlocale error, (locale not supported on
my machine), after the error it continued loading the .mo (.po) files
from the locale folder in the app. in php 5.3 it doesn't seem to load
the files, i've tried changing the locale to the correct name for
windows wich is "enu" and the path to the correct locale folder to:
locale/
  enu/...
  en_us/...
  en_US/...
  English_United States/...
  English_United States.1252/... (changing the setlocale codeset from
"UTF-8" to "CP1252" and "1252", and various combinations of the above
settings, also with and without the codeset functions, and it didn't
show translations.

in php 5.2.10 it loaded the files directly from the first settings
id like to know if it is possible to make php_gettext to ignore the
setlocal error and work out the folder name from the LANG and LC_ALL
enviroment variables like it apparently used to be in earlier versions
of php. or if it would be too much troublesome, then if it could be
possible to add a new function that returns the folder name where the
the .mo files are being expected to be, something like:

gettext_getpath([$text_domain = Current_default_domain])

and get something like "en_US\LC_MESSAGES\domain.mo" (locale folder
name) or the full path something like
"C:\Apache\htdocs\app\locale\en_US\LC_MESSAGES\domain.mo" or
"/var/www/app1/locale/en_US/LC_MESSAGES/domain.mo" in *nix (even if the
file doesn't exists to know if its necessary to rename/move folders

thanks in advance

Reproduce code:
---
 "hello world" (english)
in the relative path "locale/en/LC_MESSAGES/"

"hello world"

Actual result:
--
"hola mundo" (text not being translated)





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

#48324 [NEW]: oci_bind_by_name returning wrong id value

2009-05-18 Thread roger dot robins at det dot nsw dot edu dot au 
From: roger dot robins at det dot nsw dot edu dot au
Operating system: Linux Redhat ES 3.0
PHP version:  5.2.9
PHP Bug Type: OCI8 related
Bug description:  oci_bind_by_name returning wrong id value

Description:

When INSERTing a record into a table that has a database sequence for
calculating the table id (unique identifier) and that sequence's next_val
has reached double figures; and you use oci_bind_by_name to return the id
of the inserted row; then only the first digit of the two digit row id is
returned.

Code:
 $sql = "INSERT INTO {$this->prefix}$table ($fields) VALUES($values)
$returning";
$id = null;

$this->query_start($sql, $params, SQL_QUERY_INSERT);
$stmt = $this->parse_query($sql);
$descriptors = $this->bind_params($stmt, $params, $table);
if ($returning) {
  oci_bind_by_name($stmt, ":oracle_id", $id, -1, SQLT_LNG);
}
$result = oci_execute($stmt);
$this->free_descriptors($descriptors);
$this->query_end($result, $stmt);
oci_free_statement($stmt);


Reproduce code:
---
Environment:
PHP 5.2.9 compiled again Oracle 10.2 or 11.1 client, connecting to Oracle
10.2 database.

'./configure' '--with-apxs2=/usr/local/apache/bin/apxs'
'--with-mysql=/usr/bin' '--enable-soap' '--with-curl' '--with-xmlrpc'
'--enable-mbstring' '--with-openssl' '--enable-zip' '--with-ldap'
'--with-oci8=/apps/oraoid/app/oraoid/product/11.1.0/client_1' 

Expected result:

When the database table sequence reaches double figures, the correct table
(seed) id should be returned as a result of sql INSERT command and calling
oci_bind_by_name. 

Actual result:
--
The id returned is only the first digit of the real row id.

-- 
Edit bug report at http://bugs.php.net/?id=48324&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48324&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48324&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48324&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48324&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48324&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48324&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48324&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48324&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48324&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48324&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48324&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48324&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48324&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48324&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48324&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48324&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48324&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48324&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48324&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48324&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48324&r=mysqlcfg

#41350 [Com]: Error in my_thread_global_end()

2007-06-14 Thread roger dot weiss at gmail dot com 
 ID:   41350
 Comment by:   roger dot weiss at gmail dot com
 Reported By:  graham at directhostinguk dot com
 Status:   Assigned
 Bug Type: MySQL related
 Operating System: Windows 2003
 PHP Version:  5.2.2
 Assigned To:  georg
 New Comment:

This is beginning to sound like there are a bunch of Amateur Developers
 or cowboys involved with this problem rather than professions who want
to see a quality product. Rather than just point fingers both sides need
to stick their heads together and just fix the problem. 

It's the way companies that are successful get things done. I know
because in over 25 years of programming I have seen it at Microsoft,
Sundstrand, National Semiconductor, UW Medical Center, Dow Jones and
Co., and my own company. 

O wait I forgot, this is open source, no one owns anything or has any
responsibilities. When I look at the developer tab no has been assigned
or accepted responsibility for this problem.


Previous Comments:


[2007-06-12 16:31:54] chris at crgs dot co dot uk

Still a problem on PHP 5.2.3 under Windows Server 2003 / IIS 6 / MySQL
5.0.41. Can be fixed by copying libmysql.dll from PHP 5.2.1.

Seems as if neither side wants to take ownership of the bug. MySQL
people seem to say it's a PHP issue (see
http://bugs.mysql.com/bug.php?id=25621), but not much seems to be
happening here.

Can someone please fix this bug before the next release of PHP?



[2007-05-31 08:15:58] louis at steelbytes dot com

repro on win2k3.

reverting libmysql.dll to 5.2.1 fixes it.



[2007-05-29 17:04:40] php at stock-consulting dot com

I receive the message as well, when running PHP 5.2.2 from the command
line, so definitely no IIS-related issue.

The php_mysql.dll is loaded as an extension, but no functions from the
library are called by the application, so most likely no MySQL issue.
The message appeared after the PHP version update; no MySQL update was
performed. A clear indication, IMHO, the something went wrong on the PHP
side.



[2007-05-18 10:30:33] e_remove_paine at lastfrontiers dot com

With PHP5.2.2, and MySQL5.0.41 under Windows XP (IIS5.1) I can
reproduce this by simply creating a normal html page (no php tags) with
a .php extension.

Error in my_thread_global_end(): 1 threads didn't exit



[2007-05-14 01:36:28] sptong at hotmail dot com

I have upgraded to PHP 5.2.2.
I cfm that using libmysql.dll from 5.2.1, instead of 5.2.2 solved the
pbm. Or rather, the error does not show up again.



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/41350

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

#38111 [Com]: PHP crashes IIS worker process and application pool

2007-05-10 Thread roger dot weiss at gmail dot com 
 ID:   38111
 Comment by:   roger dot weiss at gmail dot com
 Reported By:  svendavidh at hotmail dot com
 Status:   No Feedback
 Bug Type: IIS related
 Operating System: Windows Server 2003 Std. Ed. R2
 PHP Version:  5.1.4
 New Comment:

I am also getting these. 

This only start happening after we installed 5.2.1.1. I will install
5.2.2 and let you know if the problem persists.

faulting module php5isapi.dll, version 5.2.1.1, fault address
0x23d7


Previous Comments:


[2007-04-09 13:09:36] whereismys4 at yahoo dot com

Similar problem with IIS 6.0, PHP 5.2.1.  IIS worker terminated.  This
is a problem for me since i have a firm developing a commerce website in
PHP, this is happening on a test server which has the following software
installed: 

Windows 2K3 Server R2 sp2
PHP 5.2.1
MySQL 5,0,37
IIS 6.0

I've googled this error and all threads point to PHP.  Please provide
an update to this bug.  Thanks

Mike



[2007-03-20 14:32:57] dev at e-concept dot org

I've got the same problem with php 5.2.1.1 windows vista pro II7



[2006-11-03 09:18:05] albert at siprep dot org

Same problem with PHP 5.1.6.



[2006-07-27 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-07-24 16:08:30] cyberchrist at futura dot net

svendavidh:

  MSVC6 is Microsoft Visual C++ 6.0.  Presumably, one could accomplish
the same task on later versions of Microsoft Visual Studio.  How, I
don't know, nor could I recommend installing a development studio on a
live production server.  Looks like someone needs to set up a Win2K3 R2
server offline, load up visual studio, and run the backtrace.  I have
neither the equipment nor the software to do this.  Here's hoping you
do, I just realized that I'm suffering from this same bug myself.



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/38111

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

#28804 [Com]: [FIX] lex pattern for ini-file sections wrong (affects php.ini/parse_ini_file())

2005-01-10 Thread roger at wingetsolutions dot com 
 ID:  28804
 Comment by:  roger at wingetsolutions dot com
 Reported By: wendland at scan-plus dot de
 Status:  Assigned
 Bug Type:Scripting Engine problem
 PHP Version: 4CVS, 5CVS
 Assigned To: zeev
 New Comment:

This bug does NOT affect PHP 4.3.8 on Fedora Core 3 (linux).


Previous Comments:


[2004-12-13 01:33:14] [EMAIL PROTECTED]

Zeev, please look into this sometime, or at least add a comment if
you're not going to do it?




[2004-07-06 15:55:43] [EMAIL PROTECTED]

Assigned to the author.




[2004-06-16 14:20:53] wendland at scan-plus dot de

Description:

The pattern for section in ini-files (as used in php.ini and each file
used with parse_ini_file()) is wrong.  It looks like (in
Zend/zend_ini_scanner.l:140):

[[][^[]+[\]][ ]*{NEWLINE}? 

That means that the following example won't work:

[section]
var = "val"
var2 = "]"
var3 = "val3"

Try to run this through parse_ini_file(). The pattern should look
like:

\[[^\]]+\][ ]*{NEWLINE}? 

If you'd like to disallow brackets in section name, you could use the
following pattern:

\[[^\]\[]+\][ ]*{NEWLINE}?

Kind Regards,
  Joerg Wendland







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

#25863 [Com]: IIS: The specified CGI application misbehaved

2004-09-08 Thread roger dot gusthage at home dot se 
 ID:   25863
 Comment by:   roger dot gusthage at home dot se
 Reported By:  salmanarshad2000 at yahoo dot com
 Status:   Closed
 Bug Type: CGI related
 Operating System: win32 only
 PHP Version:  4CVS, 5CVS, 6CVS..
 New Comment:

I've solved me problem by adding a redirect file between my login page
and start page. This way it seems that my use of header("Location: yada
yada"); got some breathing room and could "catch" up and smoothly go to
my start page instead of throwing a CGI error ...

I use IIS 5, W2000 server with frames on start page and got the error
only when i used header-function above or when i refresh my page
quickly. 

This is not the best solution, but could be usefull in login-situation
where i now put some text to tell the user that the login is
processing.

Redirect i used meta tag and only 1 sec delay.

Hope this might solve the problem for some of you.


Previous Comments:


[2004-06-29 12:03:00] closedbolt at gmx dot de

Seems like php.exe in php 5 rc3 does not prepend any headers.
--> cgi error in IIS 
php-cgi.exe does... --> works fine for me now.

Example:

test.php 
 

C:\php>php.exe test.php
hi
C:\php>php-cgi.exe test.php
Content-type: text/html
X-Powered-By: PHP/5.0.0RC3

hi
C:\php>



[2004-06-23 18:38:14] tincanmann at hotmail dot com

Hi, thanks for all the other posts and hopefully this can help someone
else!

I also struggled with this problem of getting PHP to run on IIS.  I
solved it slightly differently on my development server to the live
production server, both running Win2003 Server (production being more
patched, secure, etc).

1) Ensure anonymous access not allowed by editing the website details
in IIS.
This solved my one server but not the other.  However, it all seems to
stem from the security and permissions.

2) Try access the website using https:// instead of http:// ...
strange, I know, but it worked for the production server (and saved me
having to rewrite in ASP).

Gareth



[2004-05-26 15:36:11] onderoz at zmail dot sk

PHP5 Release candidate 2 + IIS5 on W2K Advanced Server.

Still having the same problem.. The damned CGI misbehaved bla bla bla..


I need a complete SOLUTION for this, not WORKAROUND, if we're talking
about a complete language.
What i did :
1.. Downloaded *latest* version of the PHP (5 RC2)
2.. Expanded zip file to the directory C:\PHP5\
3.. added paths to PATH as C:\PHP5;C:\PHP5\EXT as in folder tree.
4.. added extension .php and .php5 with c:\php5\php.exe %s %S
5.. added extension to HKEY_CLASSES_ROOT
6.. added pathinfo to HKEY_LOCAL_MACHINE
7.. gave permissions -full control- to IUSR_*, IWAM_*, EVERYONE on
C:\PHP5 and c:\inetpub\wwwroot\PHP5SCRIPTS
8.. edited php.ini file 
a. cgi.force_redirect=0
b. ;doc_root=

so.. what's next?!?
1.. how should I get this system working with PHP?
2.. do I have to mess with these with every new
installation/upgrade/system change?

thanks folks, for *not* helping us newbies by not providing an
automated system for the installation process.

Onder



[2004-05-08 20:20:53] dmeeking at shaw dot ca

I found that excluding c:\php\ from my (Norton) virus scanner fixed the
problem.  Some comments led me to believe that windows was getting
grumpy when multiple requests were being handled by php.exe.  This made
me wonder if the antivirus was locking the file, since it was set to
scan every exe upon execution.  Turning off scanning on the PHP folder
has fixed this problem for me (iis5 / PHP 4.3.6).



[2004-04-28 18:19:25] david dot blair at nsi1 dot com

I need to retract my earlier statement of: 
"After the reset, the CGI errors occurred only once per page."

3 days in and we've had a couple reoccurring page errors...the
frequency is going down, or people aren't getting back to me on the
problem...the latter is most likely the case here.

I should also state that we are running IIS 6 on 2003(I previously
wrote 2000...my fault)



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/25863

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

#14973 [Com]: Mail sent by www-data on behalf of the user

2004-08-16 Thread roger at ninthave dot net 
 ID:   14973
 Comment by:   roger at ninthave dot net
 Reported By:  mcoughlan at gothambroadband dot com
 Status:   Bogus
 Bug Type: IMAP related
 Operating System: Debian Linux Woody
 PHP Version:  4.1.0
 New Comment:

I have had the same problem using Exim, and noticed that  
the offending emails always had the Sender: header set.  
>From the exim man page I saw:  
  
Allowing untrusted users to change the  sender  address   
does not  of  itself make it possible to send anonymous  
mail. Exim still checks that the From: header refers to  
the local user, and if it does not, it adds a Sender:  
header, though this can be overridden by setting  
"no_local_from_check".  
  
Adding this directive in the global settings of exim4.conf  
fixed it for me - although I couldn't find this directive  
in the exim docs (?)


Previous Comments:


[2002-01-14 12:53:31] mcoughlan at gothambroadband dot com

Thanks for the personal reply regarding our bug report below, Jim.  

The IMP, Postfix, and PHP lists have given no insight into our
solution. If you have any idea where to fix this in our MTA, please let
me know.  

Also, is it possible that it could be an IMAP issue or Apache issue? Do
you know for sure the running MTA is the problem?  Could it be say, an
apache compile issue?

It seems strange that postfix would take the liberty of affecting the
header in this way. Any keywords for searching, aside from "on behalf"
would be appreciated.

Thanks

MC



[2002-01-10 12:51:54] [EMAIL PROTECTED]

this is a mta configuration issue.



[2002-01-10 12:44:00] mcoughlan at gothambroadband dot com

We are using HORDE 2 and IMP 3. Mail sent via IMP webmail comes "From
www-data on behalf of" the imp user.  www-data is the apache account,
of course. 

As far as I can tell, this only happens with local routing via IMP, not
via Outlook routing locally, or with IMP sending to outside accounts.

The problem is that this breaks the Outlook "search from" feature.  One
must search for "www-data" in the Inbox, which of course is not
correct.

Past postings to the IMP list indicate this is a PHP-IMAP issue..?

PHP Version: 4.1.0RC2 
PHP Major Version: 4.1 
PHP Minor Version: 0 
PHP Version Classification: dev 
You are running a supported version of PHP.
MTA = postfix-20011008snapshot-1
IMAP = courier





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

#19541 [Com]: mssql_connect fails under stress

2004-03-12 Thread roger dot flink at easit dot se 
 ID:   19541
 Comment by:   roger dot flink at easit dot se
 Reported By:  mlaukast1 at hotmail dot com
 Status:   No Feedback
 Bug Type: MSSQL related
 Operating System: Windows NT4(SP6)
 PHP Version:  4.2.3
 New Comment:

I have the same problem mentioned above... :(


Previous Comments:


[2002-12-23 01:00:04] php-bugs at lists dot php dot net

No feedback was provided for this bug for over 2 weeks, 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".



[2002-12-07 01:38:08] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-09-23 17:22:22] mlaukast1 at hotmail dot com

I switched to CGI and I can confirm that the error doesn't occur
anymore. However, as I expected I've run into some serious performance
problems under heavy load (CPU usage extremely high, script execution
timeouts etc.). Therefore I'd really like to see this working under
ISAPI as well. 



Does this error suggest that the mssql extension has problems with
thread safety?



My opinion is that if ISAPI was stable and working well, it would be a
major break-through for the PHP in Windows platforms. I honestly hope
PHP group is taking Windows platforms seriously and putting effort to
them.



[2002-09-21 10:40:49] mlaukast1 at hotmail dot com

I have found out that mssql_connect fails under stress. I'm using PHP
4.2.3/ISAPI on IIS4/NT4(SP6). MSSQL 7.0 Server is a dedicated dual
processor server with NT4(SP6). I've installed MDAC 2.7 RTM on the web
server and performance setting is set to foreground applications (read
bug: 9852).



I've despertately searched solution to this problem, since the site I'm
running is on production state already. I experienced this bug with PHP
4.2.2 at first then moved on to 4.2.3 without any change to the
problem. The error occurs on a line:



$dbconn = mssql_connect($dbalias,$dbuser,$dbpw);



and application log entry for the error is:



The description for Event ID ( 2000 ) in Source ( c-client ) could not
be found. It contains the following insertion string(s): , PHP
Warning:  MS SQL:  Unable to connect to server:  *dbname* in *path* on
line x.



I'm using TCP/IP protocol, however I've tried named pipes and
multiprotocol without help. I've tried to work around this problem and
I found out that usually this error occurs when several users are
trying to connect to the database simultaneously. I managed to reduce
the appearance of the error with the code:



function usleepWindows($usec)

{

$start = gettimeofday();



do

{

$stop = gettimeofday();

$timePassed = 100 * ($stop['sec'] - $start['sec'])

+ $stop['usec'] - $start['usec'];

}

while ($timePassed < $usec);

}



$tries=11;

$totaldelay=0;

// Set db connection

$dbconn = mssql_connect($dbalias,$dbuser,$dbpw);

while(!$dbconn){

if ($tries<=0){

echo "Database failed to respond.";

$fp = fopen("c:\\logs\\conn_failed.log","a");

fputs($fp, gmdate("M d Y H:i:s") . ": db connection failed. Total
delay: $totaldelay. From: $REMOTE_HOST.\r\n");

fclose($fp);

exit;

}

$delay=mt_rand(8, 15);

usleepWindows($delay);

$conn = mssql_connect($dbalias,$dbuser,$dbpw);

$tries--;

$totaldelay += $delay;

}



The function usleepWindows was found from
http://www.php.net/manual/en/function.usleep.php.



I haven't tried the CGI yet and wouldn't want to since it will surely
suffocate the web server under load. ISAPI is far more superior and my
other experiences of it are very positive.



I hope to find a solid answer to this problem as it very critical to my
site.






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

#23220 [Com]: fgets() causes warning while reading data via SSL channel (HTTPS)

2003-12-29 Thread Roger dot Schweppe at cbsks dot com 
 ID:   23220
 Comment by:   Roger dot Schweppe at cbsks dot com
 Reported By:  storozhilov at mail dot ru
 Status:   No Feedback
 Bug Type: Filesystem function related
 Operating System: FreeBSD 4.8
 PHP Version:  4-STABLE-200307070330
 Assigned To:  wez
 New Comment:

I have been having the same problem with IIS 5.  So if you ever find a
solution I would be very happy to hear from you. 

Thanks,
Roger


Previous Comments:


[2003-12-23 14:02:46] pta at interkan dot net

Forgot to include this info:

PHP 4.3.4 (cli) (built: Dec  4 2003 11:17:45)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies



[2003-12-23 14:01:39] pta at interkan dot net

I've been experiencing the same problem with PHP 4.3.4 running on a
Linux Slackware/Apache server.  The problem did initially crop up
inside the PEAR Socket class which I'm trying to use to connect to
Authorize.Net's gateway.  Here's the exact message returned (with path
changes):

Warning: fread(): SSL: fatal protocol error in /path/to/Net/Socket.php
on line 243



[2003-12-12 20:59:12] tim at timcrider dot com

oh by the way. I am trying this with https:// as wez requested and am
reproducing the same error:

PHP 5.0.0b2 (cli) (built: Dec  7 2003 18:04:51)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies
with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St.
Petersburg, by Dmitry Stogov



[2003-12-12 20:54:11] tim at timcrider dot com

I am having the same problem on Red Hat 9.0 with PHP 5.0 B2. It's
coming from Net/Socket.php



[2003-12-04 02:24:40] [EMAIL PROTECTED]

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.





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/23220

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

Bug #17185: Bad error message

2002-05-13 Thread roger 

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.5
PHP version:  4.1.2
PHP Bug Type: Filesystem function related
Bug description:  Bad error message

When using readfile("http://domain.com/xxx.html";) where xxx.html does not
exist (404), readfile generates the warning...

Warning: readfile("http://www.wheelpro.co.uk/xxx.html";) - Message too long
in /home/roger/wheelpro/htdocs/read.php on line 11

Message too long???

However, regardless of any message I would still expect the 404 output
from the server?
-- 
Edit bug report at http://bugs.php.net/?id=17185&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=17185&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17185&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=17185&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=17185&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17185&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=17185&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17185&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17185&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17185&r=globals

Bug #15628 Updated: Multiple Connections not allowed

2002-02-22 Thread roger 

 ID:   15628
 Updated by:   [EMAIL PROTECTED], [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Informix related
 Operating System: SunSolaris 8 Sparc
 PHP Version:  4.1.1
 New Comment:

Some information:

SO - Red Hat 7.1 kernel 2.2.12

The file to be edited is ext/informix/ifx.ec


Previous Comments:


[2002-02-22 12:22:36] [EMAIL PROTECTED], [EMAIL PROTECTED]

we´ve found the same bug.
This solution worked very well!
Thanks!



[2002-02-19 14:29:36] [EMAIL PROTECTED]

Hi,

I would like to report a bug in the Informix module of PHP 4.1.1.

When you try to use more than one connection, the last connection
created is the one that receives every statement, and under this
circumstances you may get a SQLCODE error code -206 when calling
ifx_query as the table may not exist in the current database. 

I was debugging the Informix implementation and I found that in the
function ifx_query the following statement is missing:

  EXEC SQL set connection :ifx;

before the call of the macro PHP_IFX_CHECK_CONNECTION and the call to
the PREPARE statement. If you add that statement, the funcion ifx_query
works fine.

This function call is needed as every time that you execute the
statement CONNECT TO ... that connection is the active one and the
former connections become dormant. When you want to use one of those
connection, you need to active it again using the statement SET
CONNECTION.

I hope this helps.




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

Bug #15628 Updated: Multiple Connections not allowed

2002-02-22 Thread roger 

 ID:   15628
 Updated by:   [EMAIL PROTECTED], [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Informix related
 Operating System: SunSolaris 8 Sparc
 PHP Version:  4.1.1
 New Comment:

we´ve found the same bug.
This solution worked very well!
Thanks!


Previous Comments:


[2002-02-19 14:29:36] [EMAIL PROTECTED]

Hi,

I would like to report a bug in the Informix module of PHP 4.1.1.

When you try to use more than one connection, the last connection
created is the one that receives every statement, and under this
circumstances you may get a SQLCODE error code -206 when calling
ifx_query as the table may not exist in the current database. 

I was debugging the Informix implementation and I found that in the
function ifx_query the following statement is missing:

  EXEC SQL set connection :ifx;

before the call of the macro PHP_IFX_CHECK_CONNECTION and the call to
the PREPARE statement. If you add that statement, the funcion ifx_query
works fine.

This function call is needed as every time that you execute the
statement CONNECT TO ... that connection is the active one and the
former connections become dormant. When you want to use one of those
connection, you need to active it again using the statement SET
CONNECTION.

I hope this helps.




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