exception throw from __autoload could not be catched on php 5.3.1

--0016e68ef4808dbaff047e46a1ee
Content-Type: text/plain; charset=UTF-8

Hi php-dev pros,

I got an issue about catching exception throw from __autoload on php 5.3.1.

The manual state that exception throw from __autoload could be catched with
try.. catch statement same as the normal flow.

But I'can archive that even I have copied the same sample code from the
manual.

Here are the code segment.

[[[
function __autoload($name) {
echo "Want to load $name.\n";
throw new Exception("Unable to load $name.");
}

try {
$obj = new NonLoadableClass();
} catch (Exception $e) {
echo $e->getMessage(), "\n";
}

]]]

Are there anyone experienced this or not ?

Thanks in advance !

Regards,
Eric,

--0016e68ef4808dbaff047e46a1ee--

RE: exception throw from __autoload could not be catchedon php 5.3.1

WWVzLCBJIGFtIGFsc28gYWJsZSB0byByZXByb2R1Y2UgdGhpcyBpbiB0aGUg YnJvd3NlciB1c2lu
ZyBib3RoIDUuMy4xIGFzIHdlbGwgYXMgNS4zLjAgb24gV2luZG93cyB1c2lu ZyBJSVMuDQoNClNl
ZW1zIGxpa2UgYSBidWcuDQoNCllvdSBtYXkgbGlrZSB0byBmaWxlIHRoZSBi dWcgYXQgaHR0cDov
L2J1Z3MucGhwLm5ldC4NCg0KVGhhbmtzLA0KRG9uLg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogRXJpYyBMZWUgW21haWx0bzpwZ2VyaWNAZ21haWwuY29t XSANClNlbnQ6IFRo
dXJzZGF5LCBKYW51YXJ5IDI4LCAyMDEwIDk6MDkgUE0NClRvOiBwaHAtd2lu ZG93c0BsaXN0cy5w
aHAubmV0DQpTdWJqZWN0OiBbUEhQLVdJTl0gZXhjZXB0aW9uIHRocm93IGZy b20gX19hdXRvbG9h
ZCBjb3VsZCBub3QgYmUgY2F0Y2hlZCBvbiBwaHAgNS4zLjENCg0KSGkgcGhw LWRldiBwcm9zLA0K
DQpJIGdvdCBhbiBpc3N1ZSBhYm91dCBjYXRjaGluZyBleGNlcHRpb24gdGhy b3cgZnJvbSBfX2F1
dG9sb2FkIG9uIHBocCA1LjMuMS4NCg0KVGhlIG1hbnVhbCBzdGF0ZSB0aGF0 IGV4Y2VwdGlvbiB0
aHJvdyBmcm9tIF9fYXV0b2xvYWQgY291bGQgYmUgY2F0Y2hlZCB3aXRoDQp0 cnkuLiBjYXRjaCBz
dGF0ZW1lbnQgc2FtZSBhcyB0aGUgbm9ybWFsIGZsb3cuDQoNCkJ1dCBJJ2Nh biBhcmNoaXZlIHRo
YXQgZXZlbiBJIGhhdmUgY29waWVkIHRoZSBzYW1lIHNhbXBsZSBjb2RlIGZy b20gdGhlDQptYW51
YWwuDQoNCkhlcmUgYXJlIHRoZSBjb2RlIHNlZ21lbnQuDQoNCltbWw0KZnVu Y3Rpb24gX19hdXRv
bG9hZCgkbmFtZSkgew0KICAgZWNobyAiV2FudCB0byBsb2FkICRuYW1lLlxu IjsNCiAgIHRocm93
IG5ldyBFeGNlcHRpb24oIlVuYWJsZSB0byBsb2FkICRuYW1lLiIpOw0KfQ0K DQp0cnkgew0KICAg
JG9iaiA9IG5ldyBOb25Mb2FkYWJsZUNsYXNzKCk7DQp9IGNhdGNoIChFeGNl cHRpb24gJGUpIHsN
CiAgIGVjaG8gJGUtPmdldE1lc3NhZ2UoKSwgIlxuIjsNCn0NCg0KXV1dDQoN CkFyZSB0aGVyZSBh
bnlvbmUgZXhwZXJpZW5jZWQgdGhpcyBvciBub3QgPw0KDQpUaGFua3MgaW4g YWR2YW5jZSAhDQoN
ClJlZ2FyZHMsDQpFcmljLA0K

RE: exception throw from __autoload could not be catchedon php 5.3.1

T24gc2Vjb25kIHRob3VnaHQsIHRoZSBvdXRwdXQgSSBhbSBnZXR0aW5nOg0K DQpXYW50IHRvIGxv
YWQgTm9uTG9hZGFibGVDbGFzcy4gVW5hYmxlIHRvIGxvYWQgTm9uTG9hZGFi bGVDbGFzcy4NCg0K
aXMgY29uc2lzdGVudCB3aXRoIHRoZSBleGFtcGxlIG9uIHBocC5uZXQgKCBo dHRwOi8vcGhwLm5l
dC9tYW51YWwvZW4vbGFuZ3VhZ2Uub29wNS5hdXRvbG9hZC5waHAgKS4NCg0K U28gc29ycnkgYWJv
dXQgcHJldmlvdXMgbWFpbC4gVGhpcyBpcyBub3QgcmVwcm9pbmcgZm9yIG1l LiBBcmUgeW91IHJ1
bm5pbmcgaXQgdXNpbmcgUEhQIGNvbW1hbmQgbGluZT8gVGhpcyBpcyBub3Qg c3VwcG9ydGVkIGlu
IENMSSBtb2RlLiBDYW4geW91IHBhc3RlIHRoZSBvdXRwdXQgeW91IGFyZSBn ZXR0aW5nPw0KDQpJ
IG1vZGlmaWVkIHRoZSBwcm9ncmFtIHRvOg0KDQo8P3BocA0KDQpmdW5jdGlv biBfX2F1dG9sb2Fk
KCRuYW1lKSB7DQogICBlY2hvICJXYW50IHRvIGxvYWQgJG5hbWUuXG4iOw0K ICAgdGhyb3cgbmV3
IEV4Y2VwdGlvbigiVW5hYmxlIHRvIGxvYWQgJG5hbWUuIik7IH0NCg0KdHJ5 IHsNCiAgICRvYmog
PSBuZXcgTm9uTG9hZGFibGVDbGFzcygpOw0KfSBjYXRjaCAoRXhjZXB0aW9u ICRlKSB7DQogICBl
Y2hvICJEb25cbiI7DQogICBlY2hvICRlLT5nZXRNZXNzYWdlKCksICJcbiI7 DQp9DQoNCj8+DQoN
CkFuZCBJIGdldCB0aGUgb3V0cHV0IGFzOg0KV2FudCB0byBsb2FkIE5vbkxv YWRhYmxlQ2xhc3Mu
IERvbiBVbmFibGUgdG8gbG9hZCBOb25Mb2FkYWJsZUNsYXNzLg0KDQpTbyBJ IGNhbiBzZWUgJ0Rv
bicgZ2V0dGluZyBwcmludGVkIGluIHRoZSBicm93c2VyLiBQbGVhc2UgbGV0 IHVzIGtub3cgdGhl
IG91dHB1dCB5b3UgYXJlIGdldHRpbmcuDQoNClRoYW5rcywNCkRvbi4NCg0K LS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IFZlbmthdCBSYW1hbiBEb24gW21haWx0 bzpEb24uUmFtYW5A
bWljcm9zb2Z0LmNvbV0gDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyOCwg MjAxMCA5OjQ4IFBN
DQpUbzogRXJpYyBMZWU7IHBocC13aW5kb3dzQGxpc3RzLnBocC5uZXQNClN1 YmplY3Q6IFJFOiBb
UEhQLVdJTl0gZXhjZXB0aW9uIHRocm93IGZyb20gX19hdXRvbG9hZCBjb3Vs ZCBub3QgYmUgY2F0
Y2hlZCBvbiBwaHAgNS4zLjENCg0KWWVzLCBJIGFtIGFsc28gYWJsZSB0byBy ZXByb2R1Y2UgdGhp
cyBpbiB0aGUgYnJvd3NlciB1c2luZyBib3RoIDUuMy4xIGFzIHdlbGwgYXMg NS4zLjAgb24gV2lu
ZG93cyB1c2luZyBJSVMuDQoNClNlZW1zIGxpa2UgYSBidWcuDQoNCllvdSBt YXkgbGlrZSB0byBm
aWxlIHRoZSBidWcgYXQgaHR0cDovL2J1Z3MucGhwLm5ldC4NCg0KVGhhbmtz LA0KRG9uLg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRXJpYyBMZWUgW21h aWx0bzpwZ2VyaWNA
Z21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI4LCAyMDEw IDk6MDkgUE0NClRv
OiBwaHAtd2luZG93c0BsaXN0cy5waHAubmV0DQpTdWJqZWN0OiBbUEhQLVdJ Tl0gZXhjZXB0aW9u
IHRocm93IGZyb20gX19hdXRvbG9hZCBjb3VsZCBub3QgYmUgY2F0Y2hlZCBv biBwaHAgNS4zLjEN
Cg0KSGkgcGhwLWRldiBwcm9zLA0KDQpJIGdvdCBhbiBpc3N1ZSBhYm91dCBj YXRjaGluZyBleGNl
cHRpb24gdGhyb3cgZnJvbSBfX2F1dG9sb2FkIG9uIHBocCA1LjMuMS4NCg0K VGhlIG1hbnVhbCBz
dGF0ZSB0aGF0IGV4Y2VwdGlvbiB0aHJvdyBmcm9tIF9fYXV0b2xvYWQgY291 bGQgYmUgY2F0Y2hl
ZCB3aXRoDQp0cnkuLiBjYXRjaCBzdGF0ZW1lbnQgc2FtZSBhcyB0aGUgbm9y bWFsIGZsb3cuDQoN
CkJ1dCBJJ2NhbiBhcmNoaXZlIHRoYXQgZXZlbiBJIGhhdmUgY29waWVkIHRo ZSBzYW1lIHNhbXBs
ZSBjb2RlIGZyb20gdGhlDQptYW51YWwuDQoNCkhlcmUgYXJlIHRoZSBjb2Rl IHNlZ21lbnQuDQoN
CltbWw0KZnVuY3Rpb24gX19hdXRvbG9hZCgkbmFtZSkgew0KICAgZWNobyAi V2FudCB0byBsb2Fk
ICRuYW1lLlxuIjsNCiAgIHRocm93IG5ldyBFeGNlcHRpb24oIlVuYWJsZSB0 byBsb2FkICRuYW1l
LiIpOw0KfQ0KDQp0cnkgew0KICAgJG9iaiA9IG5ldyBOb25Mb2FkYWJsZUNs YXNzKCk7DQp9IGNh
dGNoIChFeGNlcHRpb24gJGUpIHsNCiAgIGVjaG8gJGUtPmdldE1lc3NhZ2Uo KSwgIlxuIjsNCn0N
Cg0KXV1dDQoNCkFyZSB0aGVyZSBhbnlvbmUgZXhwZXJpZW5jZWQgdGhpcyBv ciBub3QgPw0KDQpU
aGFua3MgaW4gYWR2YW5jZSAhDQoNClJlZ2FyZHMsDQpFcmljLA0K

Re: exception throw from __autoload could not be catched on

--0016e68eef7a9c6f1c047e4889e5
Content-Type: text/plain; charset=UTF-8

Don.


I'am sorry that the issue have been solved and that is due to I missed
something in the code ! !
And it works fine now.

Thanks for you help ! !




Regards,
Eric,




On Fri, Jan 29, 2010 at 2:08 PM, Venkat Raman Don
wrote:

> On second thought, the output I am getting:
>
> Want to load NonLoadableClass. Unable to load NonLoadableClass.
>
> is consistent with the example on php.net (
> http://php.net/manual/en/language.oop5.autoload.php ).
>
> So sorry about previous mail. This is not reproing for me. Are you running
> it using PHP command line? This is not supported in CLI mode. Can you paste
> the output you are getting?
>
> I modified the program to:
>
> >
> function __autoload($name) {
> echo "Want to load $name.\n";
> throw new Exception("Unable to load $name."); }
>
> try {
> $obj = new NonLoadableClass();
> } catch (Exception $e) {
> echo "Don\n";
> echo $e->getMessage(), "\n";
> }
>
> ?>
>
> And I get the output as:
> Want to load NonLoadableClass. Don Unable to load NonLoadableClass.
>
> So I can see 'Don' getting printed in the browser. Please let us know the
> output you are getting.
>
> Thanks,
> Don.
>
> -----Original Message-----
> From: Venkat Raman Don [mailto:Don.Raman@microsoft.com]
> Sent: Thursday, January 28, 2010 9:48 PM
> To: Eric Lee; php-windows@lists.php.net
> Subject: RE: [PHP-WIN] exception throw from __autoload could not be catched
> on php 5.3.1
>
> Yes, I am also able to reproduce this in the browser using both 5.3.1 as
> well as 5.3.0 on Windows using IIS.
>
> Seems like a bug.
>
> You may like to file the bug at http://bugs.php.net.
>
> Thanks,
> Don.
>
> -----Original Message-----
> From: Eric Lee [mailto:pgeric@gmail.com]
> Sent: Thursday, January 28, 2010 9:09 PM
> To: php-windows@lists.php.net
> Subject: [PHP-WIN] exception throw from __autoload could not be catched on
> php 5.3.1
>
> Hi php-dev pros,
>
> I got an issue about catching exception throw from __autoload on php 5.3.1.
>
> The manual state that exception throw from __autoload could be catched with
> try.. catch statement same as the normal flow.
>
> But I'can archive that even I have copied the same sample code from the
> manual.
>
> Here are the code segment.
>
> [[[
> function __autoload($name) {
> echo "Want to load $name.\n";
> throw new Exception("Unable to load $name.");
> }
>
> try {
> $obj = new NonLoadableClass();
> } catch (Exception $e) {
> echo $e->getMessage(), "\n";
> }
>
> ]]]
>
> Are there anyone experienced this or not ?
>
> Thanks in advance !
>
> Regards,
> Eric,
>

--0016e68eef7a9c6f1c047e4889e5--

A way available to test PHP CGI builds.

SGkgQWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gYW5ub3VuY2UgdGhhdCB3aXRo IHRoZSBjb21taXQg
aHR0cDovL3N2bi5waHAubmV0L3ZpZXd2Yz92aWV3PXJldmlzaW9uJnJldmlz aW9uPTI5NDIzMiwg
d2UgY2FuIGhhdmUgYSB3YXkgdG8gdGVzdCBQSFAtQ0dJLmV4ZSBvbiBXaW5k b3dzLiBNb3JlIGRl
dGFpbHMgYXJvdW5kIHRoaXMgY2FuIGJlIGZvdW5kIGF0IGh0dHA6Ly9ibG9n cy5paXMubmV0L2Rv
bnJhbWFuL2FyY2hpdmUvMjAxMC8wMi8wMS93aW5jYWNoZS10ZXN0LWNvZGUt Y29tbWl0dGVkLXRv
LXBlY2wtcGF2ZXMtYS13YXktdG8tdGVzdC1waHAtY2dpLmFzcHguDQoNCkl0 IGRvZXMgbmVlZCBz
b21lIG1vcmUgdGhpbmtpbmcgYW5kIHdvcmsuIFBsZWFzZSBsZXQgbWUga25v dyBpbiBjYXNlIHlv
dSBoYXZlIHNvbWUgaWRlYXMgYW5kIHdpbGxpbmcgdG8gY29udHJpYnV0ZS4N Cg0KVGhhbmtzLA0K
RG9uLg0K

Re: A way available to test PHP CGI builds.

hi,

On Mon, Feb 1, 2010 at 7:26 PM, Venkat Raman Don
wrote:
> Hi All,
>
> I would like to announce that with the commit http://svn.php.net/viewvc?v=
iew=3Drevision&revision=3D294232, we can have a way to test PHP-CGI.exe on =
Windows. More details around this can be found at http://blogs.iis.net/donr=
aman/archive/2010/02/01/wincache-test-code-committed-to-pecl -paves-a-way-to=
-test-php-cgi.aspx.
>
> It does need some more thinking and work. Please let me know in case you =
have some ideas and willing to contribute.

It was already possible to test php-cgi.exe just fine before by
setting the required ENVIRONMENT variables. That's what we use for the
run-tests cmd in our tree (all platforms), it supports post/upload/get
as well.

Am I mistaken or what this application does is to remote control IE to
load a given URL? This URL being the test we like to test, from the
document root? If yes, that's something relatively easy to do using
PHP directly (php supports http natively btw). It is also easy to run
the test using a given users using runas, that does not match 100% the
configuration of IIS+FCGI, but from a PHP only point of view, it
covers all cases.

Btw, take a look at the server scripts in the php src tree.

Cheers,
--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: A way available to test PHP CGI builds.

Hi Pierre,

Thanks for the comments.

I am aware of the fact that we can test php-cgi.exe in various scenarios wh=
ich is very close to real world. But my code gives the ability to test php=
-cgi.exe exactly like real world. Most of the people use PHP to host some a=
pplication. It can be home grown application, a community application or a =
variance of a community application. This is exactly what the code simulate=
s. And one more clarification it is not dependent on any server or how one =
has configured to run PHP. It can be IIS/APACHE (or any other server for th=
at matter) and is also not dependent on how you server is configured. It ca=
n be mod_php/FastCGI/ISAPI etc. So far as your code can run in the browser,=
the driver has the ability to test it. The only flaw is that it runs prima=
rily on WINDOWS as it takes a hard dependency on Internet Explorer being th=
e browser. I believe if we found this useful the hard dependency can be rem=
oved.

Thanks,
Don.

-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]=20
Sent: Monday, February 01, 2010 10:42 AM
To: Venkat Raman Don
Cc: php-windows@lists.php.net
Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.

hi,

On Mon, Feb 1, 2010 at 7:26 PM, Venkat Raman Don =
wrote:
> Hi All,
>
> I would like to announce that with the commit http://svn.php.net/viewvc?v=
iew=3Drevision&revision=3D294232, we can have a way to test PHP-CGI.exe on =
Windows. More details around this can be found at http://blogs.iis.net/donr=
aman/archive/2010/02/01/wincache-test-code-committed-to-pecl -paves-a-way-to=
-test-php-cgi.aspx.
>
> It does need some more thinking and work. Please let me know in case you =
have some ideas and willing to contribute.

It was already possible to test php-cgi.exe just fine before by setting the=
required ENVIRONMENT variables. That's what we use for the run-tests cmd i=
n our tree (all platforms), it supports post/upload/get as well.

Am I mistaken or what this application does is to remote control IE to load=
a given URL? This URL being the test we like to test, from the document ro=
ot? If yes, that's something relatively easy to do using PHP directly (php =
supports http natively btw). It is also easy to run the test using a given =
users using runas, that does not match 100% the configuration of IIS+FCGI, =
but from a PHP only point of view, it covers all cases.

Btw, take a look at the server scripts in the php src tree.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http:=
//www.php.net/unsub.php



--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: A way available to test PHP CGI builds.

On Mon, Feb 1, 2010 at 8:59 PM, Venkat Raman Don
wrote:
> Hi Pierre,
>
> Thanks for the comments.
>
> I am aware of the fact that we can test php-cgi.exe in various scenarios =
which is =A0very close to real world. But my code gives the ability to test=
php-cgi.exe exactly like real world. Most of the people use PHP to host so=
me application. It can be home grown application, a community application o=
r a variance of a community application. This is exactly what the code simu=
lates. And one more clarification it is not dependent on any server or how =
one has configured to run PHP. It can be IIS/APACHE (or any other server fo=
r that matter) and is also not dependent on how you server is configured. I=
t can be mod_php/FastCGI/ISAPI etc. So far as your code can run in the brow=
ser, the driver has the ability to test it. The only flaw is that it runs p=
rimarily on WINDOWS as it takes a hard dependency on Internet Explorer bein=
g the browser. I believe if we found this useful the hard dependency can be=
removed.

Right, but you don't need IE for that unless you want to test the JS
script inside IE (but that's not cgi related then), or do
screenshots/compare contents. The later can done using php only with
COM btw (and gd for the shots) :)

The server scripts in our source could be a good start (at least to
get some ideas), I got some inspiration from them for our tests suite.

Cheers,
--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: A way available to test PHP CGI builds.

Hi,

A good idea about using COM/GD. Let's talk about some pro/cons of it and th=
e solution I gave.
1. COM never worked with default IIS configuration because of permission is=
sues. This means again you are not simulating a real world scenario.
2. COM based solution will never have the ability to be ported to UNIX worl=
d.
3. GD can be used for screenshot comparison but any screenshot comparison w=
ill have some error of margin. Plus your thing (expected output) will be de=
pendent on screen resolution/display settings etc. If your code has to be p=
ortable going this route is not a good idea in my view.

Regarding dependency on IE, I see no reason why we cannot use a Mozilla bas=
ed browser and automate it. That way it can work on any platform though it =
will have its own challenges but not the ones we will face using GD and COM=
..

Thanks,
Don.
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]=20
Sent: Monday, February 01, 2010 12:09 PM
To: Venkat Raman Don
Cc: php-windows@lists.php.net
Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.

On Mon, Feb 1, 2010 at 8:59 PM, Venkat Raman Don =
wrote:
> Hi Pierre,
>
> Thanks for the comments.
>
> I am aware of the fact that we can test php-cgi.exe in various scenarios =
which is =A0very close to real world. But my code gives the ability to test=
php-cgi.exe exactly like real world. Most of the people use PHP to host so=
me application. It can be home grown application, a community application o=
r a variance of a community application. This is exactly what the code simu=
lates. And one more clarification it is not dependent on any server or how =
one has configured to run PHP. It can be IIS/APACHE (or any other server fo=
r that matter) and is also not dependent on how you server is configured. I=
t can be mod_php/FastCGI/ISAPI etc. So far as your code can run in the brow=
ser, the driver has the ability to test it. The only flaw is that it runs p=
rimarily on WINDOWS as it takes a hard dependency on Internet Explorer bein=
g the browser. I believe if we found this useful the hard dependency can be=
removed.

Right, but you don't need IE for that unless you want to test the JS script=
inside IE (but that's not cgi related then), or do screenshots/compare con=
tents. The later can done using php only with COM btw (and gd for the shots=
) :)

The server scripts in our source could be a good start (at least to get som=
e ideas), I got some inspiration from them for our tests suite.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org


--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: A way available to test PHP CGI builds.

On Mon, Feb 1, 2010 at 9:59 PM, Venkat Raman Don
wrote:
> Hi,
>
> A good idea about using COM/GD. Let's talk about some pro/cons of it and =
the solution I gave.
> 1. COM never worked with default IIS configuration because of permission =
issues. This means again you are not simulating a real world scenario.
> 2. COM based solution will never have the ability to be ported to UNIX wo=
rld.
> 3. GD can be used for screenshot comparison but any screenshot comparison=
will have some error of margin. Plus your thing (expected output) will be =
dependent on screen resolution/display settings etc. If your code has to be=
portable going this route is not a good idea in my view.
>
> Regarding dependency on IE, I see no reason why we cannot use a Mozilla b=
ased browser and automate it. That way it can work on any platform though i=
t will have its own challenges but not the ones we will face using GD and C=
OM.

Sorry, I was not clear. My point was: There is no need of a browser to
do http requests and compare the output.

For test client side results (visuallly, js, etc.), there are
excellent tools out there like selenium, but that's not what we
discuss here.

Cheers,
--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: A way available to test PHP CGI builds.

Hi,

Let's don't argue just for the heck of it.

Can I know why browser is not a good thing. And what solution you are arriv=
ing into. And can you help me share the coding for that solution if we find=
it better. And BTW my solution doesn't involve comparing screenshot.

I think I have given enough reason why not to use GD/COM. Do you still thin=
k using COM/GD is a viable option? Or you have another alternative? I alrea=
dy told you we can use Mozilla based browser which can be used across platf=
orm. Ideally a solution should be scalable and work on different matrix.

Thanks,
Don.

-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]=20
Sent: Monday, February 01, 2010 1:04 PM
To: Venkat Raman Don
Cc: php-windows@lists.php.net
Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.

On Mon, Feb 1, 2010 at 9:59 PM, Venkat Raman Don
wrote:
> Hi,
>
> A good idea about using COM/GD. Let's talk about some pro/cons of it and =
the solution I gave.
> 1. COM never worked with default IIS configuration because of permission =
issues. This means again you are not simulating a real world scenario.
> 2. COM based solution will never have the ability to be ported to UNIX wo=
rld.
> 3. GD can be used for screenshot comparison but any screenshot comparison=
will have some error of margin. Plus your thing (expected output) will be =
dependent on screen resolution/display settings etc. If your code has to be=
portable going this route is not a good idea in my view.
>
> Regarding dependency on IE, I see no reason why we cannot use a Mozilla b=
ased browser and automate it. That way it can work on any platform though i=
t will have its own challenges but not the ones we will face using GD and C=
OM.

Sorry, I was not clear. My point was: There is no need of a browser to
do http requests and compare the output.

For test client side results (visuallly, js, etc.), there are
excellent tools out there like selenium, but that's not what we
discuss here.

Cheers,
--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--=20
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: A way available to test PHP CGI builds.

hi,

Let me start from scratch:

To test the output of a http request, no browser is required. PHP
alone suffices, or wget/curl cmd line (or other similar tools). PHP
supports HTTP (incl. headers), the diff can be generated easily, see
run-tests.php.

The only reason why a browser would be required is to compare the
visual output or how js behaves. That's where GD could help, to
compare screenshots of the rendered page. But that's not what we neeed
here.

That's what I was trying to explain.

Cheers,
--
Pierre

On Tue, Feb 2, 2010 at 7:37 AM, Venkat Raman Don
wrote:
> Hi,
>
> Let's don't argue just for the heck of it.
>
> Can I know why browser is not a good thing. And what solution you are arr=
iving into. And can you help me share the coding for that solution if we fi=
nd it better. And BTW my solution doesn't involve comparing screenshot.
>
> I think I have given enough reason why not to use GD/COM. Do you still th=
ink using COM/GD is a viable option? Or you have another alternative? I alr=
eady told you we can use Mozilla based browser which can be used across pla=
tform. Ideally a solution should be scalable and work on different matrix.
>
> Thanks,
> Don.
>
> -----Original Message-----
> From: Pierre Joye [mailto:pierre.php@gmail.com]
> Sent: Monday, February 01, 2010 1:04 PM
> To: Venkat Raman Don
> Cc: php-windows@lists.php.net
> Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
>
> On Mon, Feb 1, 2010 at 9:59 PM, Venkat Raman Don
> wrote:
>> Hi,
>>
>> A good idea about using COM/GD. Let's talk about some pro/cons of it and=
the solution I gave.
>> 1. COM never worked with default IIS configuration because of permission=
issues. This means again you are not simulating a real world scenario.
>> 2. COM based solution will never have the ability to be ported to UNIX w=
orld.
>> 3. GD can be used for screenshot comparison but any screenshot compariso=
n will have some error of margin. Plus your thing (expected output) will be=
dependent on screen resolution/display settings etc. If your code has to b=
e portable going this route is not a good idea in my view.
>>
>> Regarding dependency on IE, I see no reason why we cannot use a Mozilla =
based browser and automate it. That way it can work on any platform though =
it will have its own challenges but not the ones we will face using GD and =
COM.
>
> Sorry, I was not clear. My point was: There is no need of a browser to
> do http requests and compare the output.
>
> For test client side results (visuallly, js, etc.), there are
> excellent tools out there like selenium, but that's not what we
> discuss here.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>



--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: A way available to test PHP CGI builds.

Hi,

Pierre, I understand that there are alternate ways. I was just asking why t=
he browser way is bad or not acceptable? Or you are okay with browser way a=
nd suggesting an alternative. If you have concerns regarding using browser =
to test, I would like to know it as it also impacts WINCACHE quality overal=
l.

Thanks,
Don.

-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]=20
Sent: Tuesday, February 02, 2010 1:21 AM
To: Venkat Raman Don
Cc: php-windows@lists.php.net
Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.

hi,

Let me start from scratch:

To test the output of a http request, no browser is required. PHP
alone suffices, or wget/curl cmd line (or other similar tools). PHP
supports HTTP (incl. headers), the diff can be generated easily, see
run-tests.php.

The only reason why a browser would be required is to compare the
visual output or how js behaves. That's where GD could help, to
compare screenshots of the rendered page. But that's not what we neeed
here.

That's what I was trying to explain.

Cheers,
--
Pierre

On Tue, Feb 2, 2010 at 7:37 AM, Venkat Raman Don
wrote:
> Hi,
>
> Let's don't argue just for the heck of it.
>
> Can I know why browser is not a good thing. And what solution you are arr=
iving into. And can you help me share the coding for that solution if we fi=
nd it better. And BTW my solution doesn't involve comparing screenshot.
>
> I think I have given enough reason why not to use GD/COM. Do you still th=
ink using COM/GD is a viable option? Or you have another alternative? I alr=
eady told you we can use Mozilla based browser which can be used across pla=
tform. Ideally a solution should be scalable and work on different matrix.
>
> Thanks,
> Don.
>
> -----Original Message-----
> From: Pierre Joye [mailto:pierre.php@gmail.com]
> Sent: Monday, February 01, 2010 1:04 PM
> To: Venkat Raman Don
> Cc: php-windows@lists.php.net
> Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
>
> On Mon, Feb 1, 2010 at 9:59 PM, Venkat Raman Don
> wrote:
>> Hi,
>>
>> A good idea about using COM/GD. Let's talk about some pro/cons of it and=
the solution I gave.
>> 1. COM never worked with default IIS configuration because of permission=
issues. This means again you are not simulating a real world scenario.
>> 2. COM based solution will never have the ability to be ported to UNIX w=
orld.
>> 3. GD can be used for screenshot comparison but any screenshot compariso=
n will have some error of margin. Plus your thing (expected output) will be=
dependent on screen resolution/display settings etc. If your code has to b=
e portable going this route is not a good idea in my view.
>>
>> Regarding dependency on IE, I see no reason why we cannot use a Mozilla =
based browser and automate it. That way it can work on any platform though =
it will have its own challenges but not the ones we will face using GD and =
COM.
>
> Sorry, I was not clear. My point was: There is no need of a browser to
> do http requests and compare the output.
>
> For test client side results (visuallly, js, etc.), there are
> excellent tools out there like selenium, but that's not what we
> discuss here.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>



--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org


--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: A way available to test PHP CGI builds.

On Tue, Feb 2, 2010 at 5:06 PM, Venkat Raman Don
wrote:
> Hi,
>
> Pierre, I understand that there are alternate ways. I was just asking why=
the browser way is bad or not acceptable? Or you are okay with browser way=
and suggesting an alternative. If you have concerns regarding using browse=
r to test, I would like to know it as it also impacts WINCACHE quality over=
all.
>
Why are you using something what isn't needed? If you dont need the
rendered layout, executed client side js, then what are the advantages
using a browser over a php module?

Tyrael
> Thanks,
> Don.
>
> -----Original Message-----
> From: Pierre Joye [mailto:pierre.php@gmail.com]
> Sent: Tuesday, February 02, 2010 1:21 AM
> To: Venkat Raman Don
> Cc: php-windows@lists.php.net
> Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
>
> hi,
>
> Let me start from scratch:
>
> To test the output of a http request, no browser is required. PHP
> alone suffices, or wget/curl cmd line (or other similar tools). PHP
> supports HTTP (incl. headers), the diff can be generated easily, see
> run-tests.php.
>
> The only reason why a browser would be required is to compare the
> visual output or how js behaves. That's where GD could help, to
> compare screenshots of the rendered page. But that's not what we neeed
> here.
>
> That's what I was trying to explain.
>
> Cheers,
> --
> Pierre
>
> On Tue, Feb 2, 2010 at 7:37 AM, Venkat Raman Don
> wrote:
>> Hi,
>>
>> Let's don't argue just for the heck of it.
>>
>> Can I know why browser is not a good thing. And what solution you are ar=
riving into. And can you help me share the coding for that solution if we f=
ind it better. And BTW my solution doesn't involve comparing screenshot.
>>
>> I think I have given enough reason why not to use GD/COM. Do you still t=
hink using COM/GD is a viable option? Or you have another alternative? I al=
ready told you we can use Mozilla based browser which can be used across pl=
atform. Ideally a solution should be scalable and work on different matrix.
>>
>> Thanks,
>> Don.
>>
>> -----Original Message-----
>> From: Pierre Joye [mailto:pierre.php@gmail.com]
>> Sent: Monday, February 01, 2010 1:04 PM
>> To: Venkat Raman Don
>> Cc: php-windows@lists.php.net
>> Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
>>
>> On Mon, Feb 1, 2010 at 9:59 PM, Venkat Raman Don
>> wrote:
>>> Hi,
>>>
>>> A good idea about using COM/GD. Let's talk about some pro/cons of it an=
d the solution I gave.
>>> 1. COM never worked with default IIS configuration because of permissio=
n issues. This means again you are not simulating a real world scenario.
>>> 2. COM based solution will never have the ability to be ported to UNIX =
world.
>>> 3. GD can be used for screenshot comparison but any screenshot comparis=
on will have some error of margin. Plus your thing (expected output) will b=
e dependent on screen resolution/display settings etc. If your code has to =
be portable going this route is not a good idea in my view.
>>>
>>> Regarding dependency on IE, I see no reason why we cannot use a Mozilla=
based browser and automate it. That way it can work on any platform though=
it will have its own challenges but not the ones we will face using GD and=
COM.
>>
>> Sorry, I was not clear. My point was: There is no need of a browser to
>> do http requests and compare the output.
>>
>> For test client side results (visuallly, js, etc.), there are
>> excellent tools out there like selenium, but that's not what we
>> discuss here.
>>
>> Cheers,
>> --
>> Pierre
>>
>> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>>
>> --
>> PHP Windows Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>
>
>
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: A way available to test PHP CGI builds.

SGksDQoNClRoZSByZWFzb24gSSBhbSB1c2luZyBicm93c2VyIGlzIGJlY2F1 c2UgSSB3YW50ZWQg
dG8gc2ltdWxhdGUgdGhlIHdheSBzZXJ2ZXIgd29ya3MuIA0KDQpUaGFua3Mg Zm9yIGFsbCB0aGUg
aW5wdXQuIEkgd2lsbCBsb29rIGludG8gb3RoZXIgbW9kdWxlcyBhbmQgc2Vl IGlmIGEgc2ltaWxh
ciB0aGluZyBjYW4gYmUgYWNoaWV2ZWQgdXNpbmcgUEhQIGl0c2VsZi4NCg0K RG9uLg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRmVyZW5jIEtvdmFjcyBb bWFpbHRvOnR5cmEz
bEBnbWFpbC5jb21dIA0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDIsIDIw MTAgODoyOSBBTQ0K
VG86IFZlbmthdCBSYW1hbiBEb24NCkNjOiBQaWVycmUgSm95ZTsgcGhwLXdp bmRvd3NAbGlzdHMu
cGhwLm5ldA0KU3ViamVjdDogUmU6IFtQSFAtV0lOXSBBIHdheSBhdmFpbGFi bGUgdG8gdGVzdCBQ
SFAgQ0dJIGJ1aWxkcy4NCg0KT24gVHVlLCBGZWIgMiwgMjAxMCBhdCA1OjA2 IFBNLCBWZW5rYXQg
UmFtYW4gRG9uIDxEb24uUmFtYW5AbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+ IEhpLA0KPg0KPiBQ
aWVycmUsIEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGFyZSBhbHRlcm5hdGUg d2F5cy4gSSB3YXMg
anVzdCBhc2tpbmcgd2h5IHRoZSBicm93c2VyIHdheSBpcyBiYWQgb3Igbm90 IGFjY2VwdGFibGU/
IE9yIHlvdSBhcmUgb2theSB3aXRoIGJyb3dzZXIgd2F5IGFuZCBzdWdnZXN0 aW5nIGFuIGFsdGVy
bmF0aXZlLiBJZiB5b3UgaGF2ZSBjb25jZXJucyByZWdhcmRpbmcgdXNpbmcg YnJvd3NlciB0byB0
ZXN0LCBJIHdvdWxkIGxpa2UgdG8ga25vdyBpdCBhcyBpdCBhbHNvIGltcGFj dHMgV0lOQ0FDSEUg
cXVhbGl0eSBvdmVyYWxsLg0KPg0KV2h5IGFyZSB5b3UgdXNpbmcgc29tZXRo aW5nIHdoYXQgaXNu
J3QgbmVlZGVkPyBJZiB5b3UgZG9udCBuZWVkIHRoZSByZW5kZXJlZCBsYXlv dXQsIGV4ZWN1dGVk
IGNsaWVudCBzaWRlIGpzLCB0aGVuIHdoYXQgYXJlIHRoZSBhZHZhbnRhZ2Vz IHVzaW5nIGEgYnJv
d3NlciBvdmVyIGEgcGhwIG1vZHVsZT8NCg0KVHlyYWVsDQo+IFRoYW5rcywN Cj4gRG9uLg0KPg0K
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQaWVycmUg Sm95ZSBbbWFpbHRv
OnBpZXJyZS5waHBAZ21haWwuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBGZWJy dWFyeSAwMiwgMjAx
MCAxOjIxIEFNDQo+IFRvOiBWZW5rYXQgUmFtYW4gRG9uDQo+IENjOiBwaHAt d2luZG93c0BsaXN0
cy5waHAubmV0DQo+IFN1YmplY3Q6IFJlOiBbUEhQLVdJTl0gQSB3YXkgYXZh aWxhYmxlIHRvIHRl
c3QgUEhQIENHSSBidWlsZHMuDQo+DQo+IGhpLA0KPg0KPiBMZXQgbWUgc3Rh cnQgZnJvbSBzY3Jh
dGNoOg0KPg0KPiBUbyB0ZXN0IHRoZSBvdXRwdXQgb2YgYSBodHRwIHJlcXVl c3QsIG5vIGJyb3dz
ZXIgaXMgcmVxdWlyZWQuIFBIUCANCj4gYWxvbmUgc3VmZmljZXMsIG9yIHdn ZXQvY3VybCBjbWQg
bGluZSAob3Igb3RoZXIgc2ltaWxhciB0b29scykuIFBIUCANCj4gc3VwcG9y dHMgSFRUUCAoaW5j
bC4gaGVhZGVycyksIHRoZSBkaWZmIGNhbiBiZSBnZW5lcmF0ZWQgZWFzaWx5 LCBzZWUgDQo+IHJ1
bi10ZXN0cy5waHAuDQo+DQo+IFRoZSBvbmx5IHJlYXNvbiB3aHkgYSBicm93 c2VyIHdvdWxkIGJl
IHJlcXVpcmVkIGlzIHRvIGNvbXBhcmUgdGhlIA0KPiB2aXN1YWwgb3V0cHV0 IG9yIGhvdyBqcyBi
ZWhhdmVzLiBUaGF0J3Mgd2hlcmUgR0QgY291bGQgaGVscCwgdG8gDQo+IGNv bXBhcmUgc2NyZWVu
c2hvdHMgb2YgdGhlIHJlbmRlcmVkIHBhZ2UuIEJ1dCB0aGF0J3Mgbm90IHdo YXQgd2UgbmVlZWQg
DQo+IGhlcmUuDQo+DQo+IFRoYXQncyB3aGF0IEkgd2FzIHRyeWluZyB0byBl eHBsYWluLg0KPg0K
PiBDaGVlcnMsDQo+IC0tDQo+IFBpZXJyZQ0KPg0KPiBPbiBUdWUsIEZlYiAy LCAyMDEwIGF0IDc6
MzcgQU0sIFZlbmthdCBSYW1hbiBEb24gDQo+IDxEb24uUmFtYW5AbWljcm9z b2Z0LmNvbT4gd3Jv
dGU6DQo+PiBIaSwNCj4+DQo+PiBMZXQncyBkb24ndCBhcmd1ZSBqdXN0IGZv ciB0aGUgaGVjayBv
ZiBpdC4NCj4+DQo+PiBDYW4gSSBrbm93IHdoeSBicm93c2VyIGlzIG5vdCBh IGdvb2QgdGhpbmcu
IEFuZCB3aGF0IHNvbHV0aW9uIHlvdSBhcmUgYXJyaXZpbmcgaW50by4gQW5k IGNhbiB5b3UgaGVs
cCBtZSBzaGFyZSB0aGUgY29kaW5nIGZvciB0aGF0IHNvbHV0aW9uIGlmIHdl IGZpbmQgaXQgYmV0
dGVyLiBBbmQgQlRXIG15IHNvbHV0aW9uIGRvZXNuJ3QgaW52b2x2ZSBjb21w YXJpbmcgc2NyZWVu
c2hvdC4NCj4+DQo+PiBJIHRoaW5rIEkgaGF2ZSBnaXZlbiBlbm91Z2ggcmVh c29uIHdoeSBub3Qg
dG8gdXNlIEdEL0NPTS4gRG8geW91IHN0aWxsIHRoaW5rIHVzaW5nIENPTS9H RCBpcyBhIHZpYWJs
ZSBvcHRpb24/IE9yIHlvdSBoYXZlIGFub3RoZXIgYWx0ZXJuYXRpdmU/IEkg YWxyZWFkeSB0b2xk
IHlvdSB3ZSBjYW4gdXNlIE1vemlsbGEgYmFzZWQgYnJvd3NlciB3aGljaCBj YW4gYmUgdXNlZCBh
Y3Jvc3MgcGxhdGZvcm0uIElkZWFsbHkgYSBzb2x1dGlvbiBzaG91bGQgYmUg c2NhbGFibGUgYW5k
IHdvcmsgb24gZGlmZmVyZW50IG1hdHJpeC4NCj4+DQo+PiBUaGFua3MsDQo+ PiBEb24uDQo+Pg0K
Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFBpZXJy ZSBKb3llIFttYWls
dG86cGllcnJlLnBocEBnbWFpbC5jb21dDQo+PiBTZW50OiBNb25kYXksIEZl YnJ1YXJ5IDAxLCAy
MDEwIDE6MDQgUE0NCj4+IFRvOiBWZW5rYXQgUmFtYW4gRG9uDQo+PiBDYzog cGhwLXdpbmRvd3NA
bGlzdHMucGhwLm5ldA0KPj4gU3ViamVjdDogUmU6IFtQSFAtV0lOXSBBIHdh eSBhdmFpbGFibGUg
dG8gdGVzdCBQSFAgQ0dJIGJ1aWxkcy4NCj4+DQo+PiBPbiBNb24sIEZlYiAx LCAyMDEwIGF0IDk6
NTkgUE0sIFZlbmthdCBSYW1hbiBEb24gDQo+PiA8RG9uLlJhbWFuQG1pY3Jv c29mdC5jb20+IHdy
b3RlOg0KPj4+IEhpLA0KPj4+DQo+Pj4gQSBnb29kIGlkZWEgYWJvdXQgdXNp bmcgQ09NL0dELiBM
ZXQncyB0YWxrIGFib3V0IHNvbWUgcHJvL2NvbnMgb2YgaXQgYW5kIHRoZSBz b2x1dGlvbiBJIGdh
dmUuDQo+Pj4gMS4gQ09NIG5ldmVyIHdvcmtlZCB3aXRoIGRlZmF1bHQgSUlT IGNvbmZpZ3VyYXRp
b24gYmVjYXVzZSBvZiBwZXJtaXNzaW9uIGlzc3Vlcy4gVGhpcyBtZWFucyBh Z2FpbiB5b3UgYXJl
IG5vdCBzaW11bGF0aW5nIGEgcmVhbCB3b3JsZCBzY2VuYXJpby4NCj4+PiAy LiBDT00gYmFzZWQg
c29sdXRpb24gd2lsbCBuZXZlciBoYXZlIHRoZSBhYmlsaXR5IHRvIGJlIHBv cnRlZCB0byBVTklY
IHdvcmxkLg0KPj4+IDMuIEdEIGNhbiBiZSB1c2VkIGZvciBzY3JlZW5zaG90 IGNvbXBhcmlzb24g
YnV0IGFueSBzY3JlZW5zaG90IGNvbXBhcmlzb24gd2lsbCBoYXZlIHNvbWUg ZXJyb3Igb2YgbWFy
Z2luLiBQbHVzIHlvdXIgdGhpbmcgKGV4cGVjdGVkIG91dHB1dCkgd2lsbCBi ZSBkZXBlbmRlbnQg
b24gc2NyZWVuIHJlc29sdXRpb24vZGlzcGxheSBzZXR0aW5ncyBldGMuIElm IHlvdXIgY29kZSBo
YXMgdG8gYmUgcG9ydGFibGUgZ29pbmcgdGhpcyByb3V0ZSBpcyBub3QgYSBn b29kIGlkZWEgaW4g
bXkgdmlldy4NCj4+Pg0KPj4+IFJlZ2FyZGluZyBkZXBlbmRlbmN5IG9uIElF LCBJIHNlZSBubyBy
ZWFzb24gd2h5IHdlIGNhbm5vdCB1c2UgYSBNb3ppbGxhIGJhc2VkIGJyb3dz ZXIgYW5kIGF1dG9t
YXRlIGl0LiBUaGF0IHdheSBpdCBjYW4gd29yayBvbiBhbnkgcGxhdGZvcm0g dGhvdWdoIGl0IHdp
bGwgaGF2ZSBpdHMgb3duIGNoYWxsZW5nZXMgYnV0IG5vdCB0aGUgb25lcyB3 ZSB3aWxsIGZhY2Ug
dXNpbmcgR0QgYW5kIENPTS4NCj4+DQo+PiBTb3JyeSwgSSB3YXMgbm90IGNs ZWFyLiBNeSBwb2lu
dCB3YXM6IFRoZXJlIGlzIG5vIG5lZWQgb2YgYSBicm93c2VyIA0KPj4gdG8g ZG8gaHR0cCByZXF1
ZXN0cyBhbmQgY29tcGFyZSB0aGUgb3V0cHV0Lg0KPj4NCj4+IEZvciB0ZXN0 IGNsaWVudCBzaWRl
IHJlc3VsdHMgKHZpc3VhbGxseSwganMsIGV0Yy4pLCB0aGVyZSBhcmUgDQo+ PiBleGNlbGxlbnQg
dG9vbHMgb3V0IHRoZXJlIGxpa2Ugc2VsZW5pdW0sIGJ1dCB0aGF0J3Mgbm90 IHdoYXQgd2UgDQo+
PiBkaXNjdXNzIGhlcmUuDQo+Pg0KPj4gQ2hlZXJzLA0KPj4gLS0NCj4+IFBp ZXJyZQ0KPj4NCj4+
IEBwaWVycmVqb3llIHwgaHR0cDovL2Jsb2cudGhlcGltcC5uZXQgfCBodHRw Oi8vd3d3LmxpYmdk
Lm9yZw0KPj4NCj4+IC0tDQo+PiBQSFAgV2luZG93cyBNYWlsaW5nIExpc3Qg KGh0dHA6Ly93d3cu
cGhwLm5ldC8pIFRvIHVuc3Vic2NyaWJlLCB2aXNpdDogDQo+PiBodHRwOi8v d3d3LnBocC5uZXQv
dW5zdWIucGhwDQo+Pg0KPj4NCj4+DQo+DQo+DQo+DQo+IC0tDQo+IFBpZXJy ZQ0KPg0KPiBAcGll
cnJlam95ZSB8IGh0dHA6Ly9ibG9nLnRoZXBpbXAubmV0IHwgaHR0cDovL3d3 dy5saWJnZC5vcmcN
Cj4NCj4NCj4gLS0NCj4gUEhQIFdpbmRvd3MgTWFpbGluZyBMaXN0IChodHRw Oi8vd3d3LnBocC5u
ZXQvKSBUbyB1bnN1YnNjcmliZSwgdmlzaXQ6IA0KPiBodHRwOi8vd3d3LnBo cC5uZXQvdW5zdWIu
cGhwDQo+DQo+DQoNCi0tDQpQSFAgV2luZG93cyBNYWlsaW5nIExpc3QgKGh0 dHA6Ly93d3cucGhw
Lm5ldC8pIFRvIHVuc3Vic2NyaWJlLCB2aXNpdDogaHR0cDovL3d3dy5waHAu bmV0L3Vuc3ViLnBo
cA0KDQoNCg==

Re: A way available to test PHP CGI builds.

Hi,

On Tue, Feb 2, 2010 at 6:13 PM, Venkat Raman Don
wrote:
> Hi,
>
> The reason I am using browser is because I wanted to simulate the way server works.

I don't want to state the obvious but servers have no idea what is
actually doing the request, whether you use telnet, curl, wget or even
a browser, is irrelevent as long as the HTTP query is valid.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php