Script running under Command Prompt or Browser or some otherapplication?

[Ojas]

Hi!,

I just out of curiosity want to know how top detect the client side
application under which the script is getting run. I mean to ask the
how to know whether the script is running under Command Prompt or
Browser or some other application?

Ojas.

[NC]

On Nov 27, 9:34 pm, Ojas <[e-mail]:

>
I just out of curiosity want to know how top detect
the client side application under which the script
is getting run. I mean to ask the how to know whether
the script is running under Command Prompt or Browser
or some other application?

This is not exactly possible. What is possible is knowing which PHP
interpreter (server module, CGI, command line, etc.) is processing the
current script:

http://www.php.net/manual/en/function.php-sapi-name.php

As to the client-side application requesting the script, the client is
under no obligation to identify itself. If it does identify itself
(by sending a "User-Agent:" request header), data sent in that header
are made available to the script as $_SERVER["HTTP_USER_AGENT"].

Cheers,
NC

[Kailash Nadh]

On Nov 28, 5:34 am, Ojas <[e-mail]:

Hi!,

I just out of curiosity want to know how top detect the client side
application under which the script is getting run. I mean to ask the
how to know whether the script is running under Command Prompt or
Browser or some other application?

Ojas.

Yep, when a php script is run from the commandline, the two variables
$argc and $argv (commandline arguments) are registered.
They might be empty, but they still would be registered when being run
from the commandline (and not when not in the commandline)
http://uk.php.net/features.commandline

--
Kailash Nadh | http://kailashnadh.name

[Jerry Stuckle]

Kailash Nadh wrote:

On Nov 28, 5:34 am, Ojas <[e-mail]:

>Hi!,

I just out of curiosity want to know how top detect the client side
application under which the script is getting run. I mean to ask the
how to know whether the script is running under Command Prompt or
Browser or some other application?

Ojas.

Yep, when a php script is run from the commandline, the two variables
$argc and $argv (commandline arguments) are registered.
They might be empty, but they still would be registered when being run
from the commandline (and not when not in the commandline)
http://uk.php.net/features.commandline

--
Kailash Nadh | http://kailashnadh.name

But that's server side. He asked about client side. And the answer is
there is no good way.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Ojas]

On Nov 28, 11:26 pm, Jerry Stuckle <[e-mail]:

Kailash Nadh wrote:

On Nov 28, 5:34 am, Ojas <[e-mail]:

Hi!,

I just out of curiosity want to know how top detect the client side
application under which the script is getting run. I mean to ask the
how to know whether the script is running under Command Prompt or
Browser or some other application?

Ojas.

Yep, when a php script is run from the commandline, the two variables
$argc and $argv (commandline arguments) are registered.
They might be empty, but they still would be registered when being run
from the commandline (and not when not in the commandline)
http://uk.php.net/features.commandline

--
Kailash Nadh |http://kailashnadh.name

But that's server side. He asked about client side. And the answer is
there is no good way.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks to all of you for replying but i still think there should be a
way to know that. Actually someone may have to implement a check on
the basis of that. Unavailability of the functionality can break the
logic!!

Ojas

[Bruno Rafael Moreira de Barros]

>Thanks to all of you for replying but i still think there should be a

>way to know that. Actually someone may have to implement a check on
the basis of that. Unavailability of the functionality can break the
logic!!

Not wanting to be pessimistic or contraditory, I think what he meant
was how to find a way to know which application executed the request.

If you open a request to a PHP script from another PHP script, there
will be a PHP user agent (dont know its name from my head), whilst on
a browser, the browsers details will be sent. Lets just say with PHP,
you can check if its command line by checking IF $argc and $argv
exist, to check if its a browser, compare it to a list of known
browsers (PHP.net has one huge file for that) and if its not run on
command line, if its not run on a known browser, then it can only be
another application.

Is that what you were looking to know, Ojas?

[Jerry Stuckle]

Ojas wrote:

On Nov 28, 11:26 pm, Jerry Stuckle <[e-mail]:

>Kailash Nadh wrote:

>>On Nov 28, 5:34 am, Ojas <[e-mail]:
Hi!,
I just out of curiosity want to know how top detect the client side
application under which the script is getting run. I mean to ask the
how to know whether the script is running under Command Prompt or
Browser or some other application?
Ojas.
Yep, when a php script is run from the commandline, the two variables
$argc and $argv (commandline arguments) are registered.
They might be empty, but they still would be registered when being run
from the commandline (and not when not in the commandline)
http://uk.php.net/features.commandline
--
Kailash Nadh |http://kailashnadh.name

But that's server side. He asked about client side. And the answer is
there is no good way.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks to all of you for replying but i still think there should be a
way to know that. Actually someone may have to implement a check on
the basis of that. Unavailability of the functionality can break the
logic!!

Ojas

Sorry - knowing what's running on the client side depends on the client
telling you. And that's not reliable.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Captain Paralytic]

On 29 Nov, 11:51, Bruno Rafael Moreira de Barros
<[e-mail]:

Thanks to all of you for replying but i still think there should be a
way to know that. Actually someone may have to implement a check on
the basis of that. Unavailability of the functionality can break the
logic!!

Not wanting to be pessimistic or contraditory, I think what he meant
was how to find a way to know which application executed the request.

If you open a request to a PHP script from another PHP script, there
will be a PHP user agent (dont know its name from my head), whilst on
a browser, the browsers details will be sent. Lets just say with PHP,
you can check if its command line by checking IF $argc and $argv
exist, to check if its a browser, compare it to a list of known
browsers (PHP.net has one huge file for that) and if its not run on
command line, if its not run on a known browser, then it can only be
another application.

Is that what you were looking to know, Ojas?

"if its not run on a known browser" and I say again, a browser does
not run a php script. A script will never be run on a browser.

[Ojas]

On Nov 29, 4:51 pm, Bruno Rafael Moreira de Barros
<[e-mail]:

Thanks to all of you for replying but i still think there should be a
way to know that. Actually someone may have to implement a check on
the basis of that. Unavailability of the functionality can break the
logic!!

Not wanting to be pessimistic or contraditory, I think what he meant
was how to find a way to know which application executed the request.

If you open a request to a PHP script from another PHP script, there
will be a PHP user agent (dont know its name from my head), whilst on
a browser, the browsers details will be sent. Lets just say with PHP,
you can check if its command line by checking IF $argc and $argv
exist, to check if its a browser, compare it to a list of known
browsers (PHP.net has one huge file for that) and if its not run on
command line, if its not run on a known browser, then it can only be
another application.

Is that what you were looking to know, Ojas?

You are right Bruno Rafael. I am willing to know the type of
application sending request to the server to run a PHP script (i think
it should be clear to all other ones that i am not asking for how
script will run on client side.)

As you have specified, if the request has been sent through command
line, $argc & $arv will exists whether having any values or not but
since we can access these values from $_SERVER (or $_ENV not sure
about it) which itself is an array, not set $_SERVER['argc'] is
equivalent to null $_SERVER['argc'], accessing the $_SERVER['argc']
will result to null values in both cases, then how one can distinguish
these cases?

Ojas.

[Jerry Stuckle]

Ojas wrote:

On Nov 29, 4:51 pm, Bruno Rafael Moreira de Barros
<[e-mail]:

>>Thanks to all of you for replying but i still think there should be a
way to know that. Actually someone may have to implement a check on
the basis of that. Unavailability of the functionality can break the
logic!!

Not wanting to be pessimistic or contraditory, I think what he meant
was how to find a way to know which application executed the request.

If you open a request to a PHP script from another PHP script, there
will be a PHP user agent (dont know its name from my head), whilst on
a browser, the browsers details will be sent. Lets just say with PHP,
you can check if its command line by checking IF $argc and $argv
exist, to check if its a browser, compare it to a list of known
browsers (PHP.net has one huge file for that) and if its not run on
command line, if its not run on a known browser, then it can only be
another application.

Is that what you were looking to know, Ojas?

You are right Bruno Rafael. I am willing to know the type of
application sending request to the server to run a PHP script (i think
it should be clear to all other ones that i am not asking for how
script will run on client side.)

PHP scripts do not run on the client side.

As you have specified, if the request has been sent through command
line, $argc & $arv will exists whether having any values or not but
since we can access these values from $_SERVER (or $_ENV not sure
about it) which itself is an array, not set $_SERVER['argc'] is
equivalent to null $_SERVER['argc'], accessing the $_SERVER['argc']
will result to null values in both cases, then how one can distinguish
these cases?

Ojas.

As he said - if it is from the command line, $argc and $argv will exist,
as will $_SERVER['argc'] and $_SERVER['argv']. But you shouldn't be
even trying to access them unless you know they exist - they will give a
NOTICE if you have errors enabled and displayed (which you should in a
development environment).

Check out isset() and array_key_exists(), for instance.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[AnrDaemon]

Greetings, Jerry Stuckle.
In reply to Your message dated Wednesday, December 5, 2007, 14:56:22,

As he said - if it is from the command line, $argc and $argv will exist,
as will $_SERVER['argc'] and $_SERVER['argv'].

Not if it is started using PHP-CGI and argc/argv vars disabled in
configuration.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[Jerry Stuckle]

AnrDaemon wrote:

Greetings, Jerry Stuckle.
In reply to Your message dated Wednesday, December 5, 2007, 14:56:22,

>As he said - if it is from the command line, $argc and $argv will exist,
as will $_SERVER['argc'] and $_SERVER['argv'].

Not if it is started using PHP-CGI and argc/argv vars disabled in
configuration.

If it's using php-cgi, then it's not started from the command line, is it?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[NC]

On Dec 5, 1:18 am, Ojas <[e-mail]:

>
if the request has been sent through command line, $argc &
$arv will exists whether having any values or not but since
we can access these values from $_SERVER (or $_ENV not sure
about it) which itself is an array, not set $_SERVER['argc']
is equivalent to null $_SERVER['argc'], accessing the
$_SERVER['argc'] will result to null values in both cases,
then how one can distinguish these cases?

There's no need to. If the script is running from the command line, a
call to php_sapi_name() will return 'cli'.

Cheers,
NC

[Ojas]

On Dec 6, 8:21 am, NC <[e-mail]:

On Dec 5, 1:18 am, Ojas <[e-mail]:

if the request has been sent through command line, $argc &
$arv will exists whether having any values or not but since
we can access these values from $_SERVER (or $_ENV not sure
about it) which itself is an array, not set $_SERVER['argc']
is equivalent to null $_SERVER['argc'], accessing the
$_SERVER['argc'] will result to null values in both cases,
then how one can distinguish these cases?

There's no need to. If the script is running from the command line, a
call to php_sapi_name() will return 'cli'.

Cheers,
NC

Hi! all,

NC has provided a very useful point of using php_sapi_name to detect
the same. I tried to print 'PHP_SAPI' on my system and got the
following result:

Browser: apache2handler
Command Prompt: cli

I think it is of great help and we are going to have a robust
solution. Meanwhile, i would appreciate if anyone of you could share
the list of all possible php sapi (along with their possible
application from which they will be in existence).

And yes Jerry Stuckle do provided the good way of distinguish between
'not set element' and 'null element' inside the array. I was known to
it, but somehow it get slipped out of my mind.

Cheers! NC & Jerry Stuckle.

To continue the discussion, i would like to extend it a little bit
further by asking how to detect whether a request to the server has
been made directly or using sockets or using CURL from the client side
application?

Ojas

[Jerry Stuckle]

Ojas wrote:

On Dec 6, 8:21 am, NC <[e-mail]:

>On Dec 5, 1:18 am, Ojas <[e-mail]:

>>if the request has been sent through command line, $argc &
$arv will exists whether having any values or not but since
we can access these values from $_SERVER (or $_ENV not sure
about it) which itself is an array, not set $_SERVER['argc']
is equivalent to null $_SERVER['argc'], accessing the
$_SERVER['argc'] will result to null values in both cases,
then how one can distinguish these cases?

There's no need to. If the script is running from the command line, a
call to php_sapi_name() will return 'cli'.

Cheers,
NC

Hi! all,

NC has provided a very useful point of using php_sapi_name to detect
the same. I tried to print 'PHP_SAPI' on my system and got the
following result:

Browser: apache2handler
Command Prompt: cli

I think it is of great help and we are going to have a robust
solution. Meanwhile, i would appreciate if anyone of you could share
the list of all possible php sapi (along with their possible
application from which they will be in existence).

And yes Jerry Stuckle do provided the good way of distinguish between
'not set element' and 'null element' inside the array. I was known to
it, but somehow it get slipped out of my mind.

Cheers! NC & Jerry Stuckle.

To continue the discussion, i would like to extend it a little bit
further by asking how to detect whether a request to the server has
been made directly or using sockets or using CURL from the client side
application?

Ojas

No way to tell. This depends on the user agent sending information,
which is not reliable. For instance, depending on the site I'm
interfacing to in CURL, I might send some string such as "PHP-CURL", or
I might send the user agent the client is using (i.e. Firefox, IE, etc.).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Ojas]

On Dec 6, 10:02 am, Jerry Stuckle <[e-mail]:

Ojas wrote:

On Dec 6, 8:21 am, NC <[e-mail]:

On Dec 5, 1:18 am, Ojas <[e-mail]:

>if the request has been sent through command line, $argc &
$arv will exists whether having any values or not but since
we can access these values from $_SERVER (or $_ENV not sure
about it) which itself is an array, not set $_SERVER['argc']
is equivalent to null $_SERVER['argc'], accessing the
$_SERVER['argc'] will result to null values in both cases,
then how one can distinguish these cases?
There's no need to. If the script is running from the command line, a
call to php_sapi_name() will return 'cli'.

Cheers,
NC

Hi! all,

NC has provided a very useful point of using php_sapi_name to detect
the same. I tried to print 'PHP_SAPI' on my system and got the
following result:

Browser: apache2handler
Command Prompt: cli

I think it is of great help and we are going to have a robust
solution. Meanwhile, i would appreciate if anyone of you could share
the list of all possible php sapi (along with their possible
applicationfrom which they will be in existence).

And yes Jerry Stuckle do provided the good way of distinguish between
'not set element' and 'null element' inside the array. I was known to
it, but somehow it get slipped out of my mind.

Cheers! NC & Jerry Stuckle.

To continue the discussion, i would like to extend it a little bit
further by asking how to detect whether a request to the server has
been made directly or using sockets or using CURL from the client side
application?

Ojas

No way to tell. This depends on the user agent sending information,
which is not reliable. For instance, depending on the site I'm
interfacing to in CURL, I might send some string such as "PHP-CURL", or
I might send the user agent the client is using (i.e. Firefox, IE, etc.).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Ok.

That's correct, but in case someone is wishing to deny the request
coming from the CURL or socket way, then what should be the procedure?

Ojas

[Jerry Stuckle]

Ojas wrote:

On Dec 6, 10:02 am, Jerry Stuckle <[e-mail]:

>Ojas wrote:

>>On Dec 6, 8:21 am, NC <[e-mail]:
On Dec 5, 1:18 am, Ojas <[e-mail]:
if the request has been sent through command line, $argc &
$arv will exists whether having any values or not but since
we can access these values from $_SERVER (or $_ENV not sure
about it) which itself is an array, not set $_SERVER['argc']
is equivalent to null $_SERVER['argc'], accessing the
$_SERVER['argc'] will result to null values in both cases,
then how one can distinguish these cases?
There's no need to. If the script is running from the command line, a
call to php_sapi_name() will return 'cli'.
Cheers,
NC
Hi! all,
NC has provided a very useful point of using php_sapi_name to detect
the same. I tried to print 'PHP_SAPI' on my system and got the
following result:
Browser: apache2handler
Command Prompt: cli
I think it is of great help and we are going to have a robust
solution. Meanwhile, i would appreciate if anyone of you could share
the list of all possible php sapi (along with their possible
applicationfrom which they will be in existence).
And yes Jerry Stuckle do provided the good way of distinguish between
'not set element' and 'null element' inside the array. I was known to
it, but somehow it get slipped out of my mind.
Cheers! NC & Jerry Stuckle.
To continue the discussion, i would like to extend it a little bit
further by asking how to detect whether a request to the server has
been made directly or using sockets or using CURL from the client side
application?
Ojas

No way to tell. This depends on the user agent sending information,
which is not reliable. For instance, depending on the site I'm
interfacing to in CURL, I might send some string such as "PHP-CURL", or
I might send the user agent the client is using (i.e. Firefox, IE, etc.).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Ok.

That's correct, but in case someone is wishing to deny the request
coming from the CURL or socket way, then what should be the procedure?

Ojas

There is none. There is no way you can tell what the client is running,
other than what the client tells you. And that is not reliable.

The real question here is - what problem are you having?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Ojas]

On Dec 6, 10:46 am, Jerry Stuckle <[e-mail]:

Ojas wrote:

On Dec 6, 10:02 am, Jerry Stuckle <[e-mail]:

Ojas wrote:
On Dec 6, 8:21 am, NC <[e-mail]:
On Dec 5, 1:18 am, Ojas <[e-mail]:
if the request has been sent through command line, $argc &
$arv will exists whether having any values or not but since
we can access these values from $_SERVER (or $_ENV not sure
about it) which itself is an array, not set $_SERVER['argc']
is equivalent to null $_SERVER['argc'], accessing the
$_SERVER['argc'] will result to null values in both cases,
then how one can distinguish these cases?
There's no need to. If the script is running from the command line, a
call to php_sapi_name() will return 'cli'.
Cheers,
NC
Hi! all,
NC has provided a very useful point of using php_sapi_name to detect
the same. I tried to print 'PHP_SAPI' on my system and got the
following result:
Browser: apache2handler
Command Prompt: cli
I think it is of great help and we are going to have a robust
solution. Meanwhile, i would appreciate if anyone of you could share
the list of all possible php sapi (along with their possible
applicationfrom which they will be in existence).
And yes Jerry Stuckle do provided the good way of distinguish between
'not set element' and 'null element' inside the array. I was known to
it, but somehow it get slipped out of my mind.
Cheers! NC & Jerry Stuckle.
To continue the discussion, i would like to extend it a little bit
further by asking how to detect whether a request to the server has
been made directly or using sockets or using CURL from the client side
application?
Ojas
No way to tell. This depends on the user agent sending information,
which is not reliable. For instance, depending on the site I'm
interfacing to in CURL, I might send some string such as "PHP-CURL", or
I might send the user agent the client is using (i.e. Firefox, IE, etc.).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Ok.

That's correct, but in case someone is wishing to deny the request
coming from the CURL or socket way, then what should be the procedure?

Ojas

There is none. There is no way you can tell what the client is running,
other than what the client tells you. And that is not reliable.

The real question here is - what problem are you having?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Well i am facing no problem at all at present.

I was just wishing to know it so that i could use the info in any of
my next projects/assignments.

As you said there is no way to track this, a spammer can develop a
script which will regularly send request to the web-server, forging
the original details??

[Norman Peelman]

Jerry Stuckle wrote:

Kailash Nadh wrote:

>On Nov 28, 5:34 am, Ojas <[e-mail]:

>>Hi!,

I just out of curiosity want to know how top detect the client side
application under which the script is getting run. I mean to ask the
how to know whether the script is running under Command Prompt or
Browser or some other application?

Ojas.

Yep, when a php script is run from the commandline, the two variables
$argc and $argv (commandline arguments) are registered.
They might be empty, but they still would be registered when being run
from the commandline (and not when not in the commandline)
http://uk.php.net/features.commandline

--
Kailash Nadh | http://kailashnadh.name

But that's server side. He asked about client side. And the answer is
there is no good way.

If the OP is trying to determine weather the program is running via a
internet server/browser or command line (terminal) then check this out.

Either of these two lines will tell you:

echo PHP_SAPI."\n\r";

or:

echo php_sapi_name()."\n";

....see: http://us.php.net/manual/en/features.commandline.php

---
Norm

[Jerry Stuckle]

Norman Peelman wrote:

Jerry Stuckle wrote:

>Kailash Nadh wrote:

>>On Nov 28, 5:34 am, Ojas <[e-mail]:
Hi!,

I just out of curiosity want to know how top detect the client side
application under which the script is getting run. I mean to ask the
how to know whether the script is running under Command Prompt or
Browser or some other application?

Ojas.

Yep, when a php script is run from the commandline, the two variables
$argc and $argv (commandline arguments) are registered.
They might be empty, but they still would be registered when being run
from the commandline (and not when not in the commandline)
http://uk.php.net/features.commandline

--
Kailash Nadh | http://kailashnadh.name

But that's server side. He asked about client side. And the answer is
there is no good way.

If the OP is trying to determine weather the program is running via a
internet server/browser or command line (terminal) then check this out.

Either of these two lines will tell you:

echo PHP_SAPI."\n\r";

or:

echo php_sapi_name()."\n";

...see: http://us.php.net/manual/en/features.commandline.php

---
Norm

That wasn't the op's question.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Ojas wrote:

On Dec 6, 10:46 am, Jerry Stuckle <[e-mail]:

>Ojas wrote:

>>On Dec 6, 10:02 am, Jerry Stuckle <[e-mail]:
Ojas wrote:
On Dec 6, 8:21 am, NC <[e-mail]:
>On Dec 5, 1:18 am, Ojas <[e-mail]:
>>if the request has been sent through command line, $argc &
>>$arv will exists whether having any values or not but since
>>we can access these values from $_SERVER (or $_ENV not sure
>>about it) which itself is an array, not set $_SERVER['argc']
>>is equivalent to null $_SERVER['argc'], accessing the
>>$_SERVER['argc'] will result to null values in both cases,
>>then how one can distinguish these cases?
>There's no need to. If the script is running from the command line, a
>call to php_sapi_name() will return 'cli'.
>Cheers,
>NC
Hi! all,
NC has provided a very useful point of using php_sapi_name to detect
the same. I tried to print 'PHP_SAPI' on my system and got the
following result:
Browser: apache2handler
Command Prompt: cli
I think it is of great help and we are going to have a robust
solution. Meanwhile, i would appreciate if anyone of you could share
the list of all possible php sapi (along with their possible
applicationfrom which they will be in existence).
And yes Jerry Stuckle do provided the good way of distinguish between
'not set element' and 'null element' inside the array. I was known to
it, but somehow it get slipped out of my mind.
Cheers! NC & Jerry Stuckle.
To continue the discussion, i would like to extend it a little bit
further by asking how to detect whether a request to the server has
been made directly or using sockets or using CURL from the client side
application?
Ojas
No way to tell. This depends on the user agent sending information,
which is not reliable. For instance, depending on the site I'm
interfacing to in CURL, I might send some string such as "PHP-CURL", or
I might send the user agent the client is using (i.e. Firefox, IE, etc.).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Ok.
That's correct, but in case someone is wishing to deny the request
coming from the CURL or socket way, then what should be the procedure?
Ojas

There is none. There is no way you can tell what the client is running,
other than what the client tells you. And that is not reliable.

The real question here is - what problem are you having?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Well i am facing no problem at all at present.

I was just wishing to know it so that i could use the info in any of
my next projects/assignments.

As you said there is no way to track this, a spammer can develop a
script which will regularly send request to the web-server, forging
the original details??

That's right.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Norman Peelman]

Jerry Stuckle wrote:

Norman Peelman wrote:

>Jerry Stuckle wrote:

>>Kailash Nadh wrote:
On Nov 28, 5:34 am, Ojas <[e-mail]:
Hi!,
>
I just out of curiosity want to know how top detect the client side
application under which the script is getting run. I mean to ask the
how to know whether the script is running under Command Prompt or
Browser or some other application?
>
Ojas.

Yep, when a php script is run from the commandline, the two variables
$argc and $argv (commandline arguments) are registered.
They might be empty, but they still would be registered when being run
from the commandline (and not when not in the commandline)
http://uk.php.net/features.commandline

--
Kailash Nadh | http://kailashnadh.name
But that's server side. He asked about client side. And the answer
is there is no good way.

If the OP is trying to determine weather the program is running via
a internet server/browser or command line (terminal) then check this out.

Either of these two lines will tell you:

echo PHP_SAPI."\n\r";

or:

echo php_sapi_name()."\n";

...see: http://us.php.net/manual/en/features.commandline.php

---
Norm

That wasn't the op's question.

I guess I took it to mean he might want to provide either a browser
interface or a terminal interface based on how the program was being
run. Possibly for scripts being run on the client machine. But i see
from the rest of the thread the true meaning of his question is now evident.

---
Norm

[AnrDaemon]

Greetings, Jerry Stuckle.
In reply to Your message dated Wednesday, December 5, 2007, 23:24:58,

>In reply to Your message dated Wednesday, December 5, 2007, 14:56:22,

>>As he said - if it is from the command line, $argc and $argv will exist,
as will $_SERVER['argc'] and $_SERVER['argv'].

Not if it is started using PHP-CGI and argc/argv vars disabled in
configuration.

If it's using php-cgi, then it's not started from the command line, is it?

You forgot that PHP-CGI *IS* a commandline executable intended to deal with
pipelined I/O from/to server.
And You still can use it instead of CLI (either knowing that or by accident).

JFYI:
<stdout>:php-cgi.exe --help
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]
php <file[args...]

[snip]
<stdout>:php.exe --help
Usage: php [options] [-f] <file[--] [args...]
php [options] -r <code[--] [args...]
php [options] [-B <begin_code>] -R <code[-E <end_code>] [--] [args...]
php [options] [-B <begin_code>] -F <file[-E <end_code>] [--] [args...]
php [options] -- [args...]
php [options] -a

[snip]
Not a big difference, You see. Basically no difference in general,
same [-f <filename>] syntax for both versions of interpreter.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[Jerry Stuckle]

AnrDaemon wrote:

Greetings, Jerry Stuckle.
In reply to Your message dated Wednesday, December 5, 2007, 23:24:58,

>>In reply to Your message dated Wednesday, December 5, 2007, 14:56:22,

As he said - if it is from the command line, $argc and $argv will exist,
as will $_SERVER['argc'] and $_SERVER['argv'].
Not if it is started using PHP-CGI and argc/argv vars disabled in
configuration.

>If it's using php-cgi, then it's not started from the command line, is it?

You forgot that PHP-CGI *IS* a commandline executable intended to deal with
pipelined I/O from/to server.
And You still can use it instead of CLI (either knowing that or by accident).

No, I didn't. CGI is NOT the same as CLI. CGI is started from a web
server. CLI is started from a command line. The processing and options
are not the same - which is partly why they have different names!

JFYI:
<stdout>:php-cgi.exe --help
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]
php <file[args...]

[snip]
<stdout>:php.exe --help
Usage: php [options] [-f] <file[--] [args...]
php [options] -r <code[--] [args...]
php [options] [-B <begin_code>] -R <code[-E <end_code>] [--] [args...]
php [options] [-B <begin_code>] -F <file[-E <end_code>] [--] [args...]
php [options] -- [args...]
php [options] -a

[snip]
Not a big difference, You see. Basically no difference in general,
same [-f <filename>] syntax for both versions of interpreter.

Ah, but there are differences. And much more than your little --help
commands show. All they have is the command line options.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[AnrDaemon]

Greetings, Jerry Stuckle.
In reply to Your message dated Saturday, December 8, 2007, 05:36:28,

>>>In reply to Your message dated Wednesday, December 5, 2007, 14:56:22,

As he said - if it is from the command line, $argc and $argv will exist,
as will $_SERVER['argc'] and $_SERVER['argv'].
Not if it is started using PHP-CGI and argc/argv vars disabled in
configuration.

>>If it's using php-cgi, then it's not started from the command line, is it?

You forgot that PHP-CGI *IS* a commandline executable intended to deal with
pipelined I/O from/to server.
And You still can use it instead of CLI (either knowing that or by accident).

No, I didn't. CGI is NOT the same as CLI. CGI is started from a web
server. CLI is started from a command line. The processing and options
are not the same - which is partly why they have different names!

Go ahead and study basics, please.

Your statement "they are different because they are intended to use in
different way" is silly.

While a hammer and an axe is not the same, what makes the difference if I use
them both to hammer the nails in the wall with exactly equal success?

Remember: rock was not intended to be weapon, but Abel was killed by the Kain
throwed it.

>JFYI:
<stdout>:php-cgi.exe --help
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]
php <file[args...]

[snip]
<stdout>:php.exe --help
Usage: php [options] [-f] <file[--] [args...]
php [options] -r <code[--] [args...]
php [options] [-B <begin_code>] -R <code[-E <end_code>] [--] [args...]
php [options] [-B <begin_code>] -F <file[-E <end_code>] [--] [args...]
php [options] -- [args...]
php [options] -a

[snip]
Not a big difference, You see. Basically no difference in general,
same [-f <filename>] syntax for both versions of interpreter.

Ah, but there are differences. And much more than your little --help
commands show. All they have is the command line options.

Show me any:

silly.php:
<?php

echo "General rant with personal attack\n";

?>

[C:\usr\sbin\php-5.2]$php.exe -f silly.php
General rant with personal attack

[C:\usr\sbin\php-5.2]$php-cgi.exe -f silly.php
General rant with personal attack

[C:\usr\sbin\php-5.2]$

Difference between CLI and CGI versions of executable is described in the
manual: CLI have forced to have argc/argv variables set and some other
things. NO OTHER difference than described in the manual.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[Jerry Stuckle]

AnrDaemon wrote:

Greetings, Jerry Stuckle.
In reply to Your message dated Saturday, December 8, 2007, 05:36:28,

>>>>In reply to Your message dated Wednesday, December 5, 2007, 14:56:22,
>
>As he said - if it is from the command line, $argc and $argv will exist,
>as will $_SERVER['argc'] and $_SERVER['argv'].
Not if it is started using PHP-CGI and argc/argv vars disabled in
configuration.
If it's using php-cgi, then it's not started from the command line, is it?
You forgot that PHP-CGI *IS* a commandline executable intended to deal with
pipelined I/O from/to server.
And You still can use it instead of CLI (either knowing that or by accident).

>No, I didn't. CGI is NOT the same as CLI. CGI is started from a web
server. CLI is started from a command line. The processing and options
are not the same - which is partly why they have different names!

Go ahead and study basics, please.

I have studied basics. Obviously a lot more than you have.

Your statement "they are different because they are intended to use in
different way" is silly.

Nope. CGI is not the same as CLI. And if you understood that you
wouldn't make the stupid claim that they are.

While a hammer and an axe is not the same, what makes the difference if I use
them both to hammer the nails in the wall with exactly equal success?

It makes a huge difference whether you're running PHP as a CGI or a CLI.
But you don't seem to understand that. Perhaps you don't even know
what CGI is.

Remember: rock was not intended to be weapon, but Abel was killed by the Kain
throwed it.

So what? Are you starting to troll, now?

>>JFYI:
<stdout>:php-cgi.exe --help
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]
php <file[args...]

[snip]
<stdout>:php.exe --help
Usage: php [options] [-f] <file[--] [args...]
php [options] -r <code[--] [args...]
php [options] [-B <begin_code>] -R <code[-E <end_code>] [--] [args...]
php [options] [-B <begin_code>] -F <file[-E <end_code>] [--] [args...]
php [options] -- [args...]
php [options] -a

[snip]
Not a big difference, You see. Basically no difference in general,
same [-f <filename>] syntax for both versions of interpreter.

>Ah, but there are differences. And much more than your little --help
commands show. All they have is the command line options.

Show me any:

You seem to know everything. You figure it out. Hint: find out what
"CGI" stands for.

silly.php:
<?php

echo "General rant with personal attack\n";

?>

[C:\usr\sbin\php-5.2]$php.exe -f silly.php
General rant with personal attack

[C:\usr\sbin\php-5.2]$php-cgi.exe -f silly.php
General rant with personal attack

Ah, now you're starting to troll. I made no personal attack on you.
But you've now started them.

[C:\usr\sbin\php-5.2]$

Difference between CLI and CGI versions of executable is described in the
manual: CLI have forced to have argc/argv variables set and some other
things. NO OTHER difference than described in the manual.

Try again. As I suggested before - figure out what CGI is. Then you
might have a clue.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Ojas wrote:

>
Hi!,

NC you have provided the list of all the available PHP SAPI but forgot
to mention when we can expect which is under existence?

Probably because that cannot be known in advance.

Also, this is very high level of intrusion being able to access the
site using CURL and socket. I can remember i access one of the site
using sockets to get the result of an particular operation to be shown
on interface of one of my project without even giving reference or
link to the output generator, of-course i would not like someone else
be able to do the same on my site. In that case how can i stop this
type of accessing?

Ojas.

That's the way the web works, and there's no way to stop it. If you
don't like it, don't use HTML. Create java applets, for instance,
instead. You'll lose a fair number of customers, but others won't be
able to use cURL. Or better yet, don't even put it on the web.

Of course, you'll lose all of the search engines, also. But heck -
you'll have your security.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[NC]

On Dec 9, 5:22 am, Ojas <[e-mail]:

On Dec 7, 8:54 pm, NC <[e-mail]:

- aolserver
- activescript
- apache
- cgi-fcgi
- cgi
- isapi
- nsapi
- phttpd
- roxen
- java_servlet
- thttpd
- pi3web
- apache2filter
- caudium
- apache2handler
- tux
- webjames
- cli
- embed
- milter

NC you have provided the list of all the available PHP SAPI but
forgot to mention when we can expect which is under existence?

The names are fairly descriptive. "aolserver", for example, means
that PHP is running under AOL Server.

Also, this is very high level of intrusion being able to access
the site using CURL and socket.

Er, and how do you think browsers access them? Through the same
sockets...

I can remember i access one of the site using sockets to get
the result of an particular operation to be shown on interface
of one of my project without even giving reference or link to
the output generator, of-course i would not like someone else
be able to do the same on my site. In that case how can i stop
this type of accessing?

You really can't. A socket program can be written to do anything a
browser does. About the only thing you can do is to obfuscate the
server-side logic by complicating the client side through the use of
Flash, Java applets, ActiveX controls, or AJAX.

Cheers,
NC

[AnrDaemon]

Greetings, Jerry Stuckle.
In reply to Your message dated Saturday, December 8, 2007, 07:28:22,

>Your statement "they are different because they are intended to use in
different way" is silly.

Nope. CGI is not the same as CLI. And if you understood that you
wouldn't make the stupid claim that they are.

Where I said that they are the same? Quote please, if You're not a troll.
I said that _they_ _can_ _be_ _used_ _the_ _same_ _way_ in the case mentioned
above - running scripts from commandline.
And without checking the SAPI used to run a script, You can't, in fact, be
sure that You are running under CLI or CGI interface. Other way, You can't (in
script) be sure You're running from commandline or started from server.
I saw many posts on forums discussing that "PHP is running almost fine on my
server but some glitches..." and that was the case of using CLI instead of CGI
executable.
If You want to say that it is impossible, good luck... but life isn't loose
it's colors just because You're blind.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[Jerry Stuckle]

AnrDaemon wrote:

Greetings, Jerry Stuckle.
In reply to Your message dated Saturday, December 8, 2007, 07:28:22,

>>Your statement "they are different because they are intended to use in
different way" is silly.

>Nope. CGI is not the same as CLI. And if you understood that you
wouldn't make the stupid claim that they are.

Where I said that they are the same? Quote please, if You're not a troll.
I said that _they_ _can_ _be_ _used_ _the_ _same_ _way_ in the case mentioned
above - running scripts from commandline.
And without checking the SAPI used to run a script, You can't, in fact, be
sure that You are running under CLI or CGI interface. Other way, You can't (in
script) be sure You're running from commandline or started from server.
I saw many posts on forums discussing that "PHP is running almost fine on my
server but some glitches..." and that was the case of using CLI instead of CGI
executable.
If You want to say that it is impossible, good luck... but life isn't loose
it's colors just because You're blind.

CGI is not run from the command line.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[AnrDaemon]

Greetings, Jerry Stuckle.
In reply to Your message dated Monday, December 10, 2007, 14:23:00,

AnrDaemon wrote:

>Greetings, Jerry Stuckle.
In reply to Your message dated Saturday, December 8, 2007, 07:28:22,

>>>Your statement "they are different because they are intended to use in
different way" is silly.

>>Nope. CGI is not the same as CLI. And if you understood that you
wouldn't make the stupid claim that they are.

Where I said that they are the same? Quote please, if You're not a troll.
I said that _they_ _can_ _be_ _used_ _the_ _same_ _way_ in the case mentioned
above - running scripts from commandline.
And without checking the SAPI used to run a script, You can't, in fact, be
sure that You are running under CLI or CGI interface. Other way, You can't (in
script) be sure You're running from commandline or started from server.
I saw many posts on forums discussing that "PHP is running almost fine on my
server but some glitches..." and that was the case of using CLI instead of CGI
executable.
If You want to say that it is impossible, good luck... but life isn't loose
it's colors just because You're blind.

CGI is not run from the command line.

I've showed the test where it does. Test please before writing.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[Jerry Stuckle]

AnrDaemon wrote:

Greetings, Jerry Stuckle.
In reply to Your message dated Monday, December 10, 2007, 14:23:00,

>AnrDaemon wrote:

>>Greetings, Jerry Stuckle.
In reply to Your message dated Saturday, December 8, 2007, 07:28:22,

Your statement "they are different because they are intended to use in
different way" is silly.
>
Nope. CGI is not the same as CLI. And if you understood that you
wouldn't make the stupid claim that they are.
Where I said that they are the same? Quote please, if You're not a troll.
I said that _they_ _can_ _be_ _used_ _the_ _same_ _way_ in the case mentioned
above - running scripts from commandline.
And without checking the SAPI used to run a script, You can't, in fact, be
sure that You are running under CLI or CGI interface. Other way, You can't (in
script) be sure You're running from commandline or started from server.
I saw many posts on forums discussing that "PHP is running almost fine on my
server but some glitches..." and that was the case of using CLI instead of CGI
executable.
If You want to say that it is impossible, good luck... but life isn't loose
it's colors just because You're blind.

>CGI is not run from the command line.

I've showed the test where it does. Test please before writing.

No. All you've done is run the CGI executable from the command line.
You cannot run a CGI program from the command line.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[AnrDaemon]

Greetings, Jerry Stuckle.
In reply to Your message dated Monday, December 10, 2007, 15:03:28,

>>>>>Your statement "they are different because they are intended to use in
>different way" is silly.
>>
Nope. CGI is not the same as CLI. And if you understood that you
wouldn't make the stupid claim that they are.
Where I said that they are the same? Quote please, if You're not a troll.
I said that _they_ _can_ _be_ _used_ _the_ _same_ _way_ in the case mentioned
above - running scripts from commandline.
And without checking the SAPI used to run a script, You can't, in fact, be
sure that You are running under CLI or CGI interface. Other way, You can't (in
script) be sure You're running from commandline or started from server.
I saw many posts on forums discussing that "PHP is running almost fine on my
server but some glitches..." and that was the case of using CLI instead of CGI
executable.
If You want to say that it is impossible, good luck... but life isn't loose
it's colors just because You're blind.

>>CGI is not run from the command line.

I've showed the test where it does. Test please before writing.

No. All you've done is run the CGI executable from the command line.
You cannot run a CGI program from the command line.

Testcase, please.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[Jerry Stuckle]

AnrDaemon wrote:

Greetings, Jerry Stuckle.
In reply to Your message dated Monday, December 10, 2007, 15:03:28,

>>>>>>Your statement "they are different because they are intended to use in
>>different way" is silly.
>>>
>Nope. CGI is not the same as CLI. And if you understood that you
>wouldn't make the stupid claim that they are.
Where I said that they are the same? Quote please, if You're not a troll.
I said that _they_ _can_ _be_ _used_ _the_ _same_ _way_ in the case mentioned
above - running scripts from commandline.
And without checking the SAPI used to run a script, You can't, in fact, be
sure that You are running under CLI or CGI interface. Other way, You can't (in
script) be sure You're running from commandline or started from server.
I saw many posts on forums discussing that "PHP is running almost fine on my
server but some glitches..." and that was the case of using CLI instead of CGI
executable.
If You want to say that it is impossible, good luck... but life isn't loose
it's colors just because You're blind.
>
>
CGI is not run from the command line.
I've showed the test where it does. Test please before writing.

>No. All you've done is run the CGI executable from the command line.
You cannot run a CGI program from the command line.

Testcase, please.

RTFM. I'm not in the business of giving you free training.

Learn what CGI is and you have your answer. Or, I will provide all the
information you want at my regular consulting rates.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[AnrDaemon]

Greetings, Jerry Stuckle.
In reply to Your message dated Monday, December 10, 2007, 23:20:11,

>>>>>>>Your statement "they are different because they are intended to use
>>>in different way" is silly.
>>>>
>>Nope. CGI is not the same as CLI. And if you understood that you
>>wouldn't make the stupid claim that they are.
>Where I said that they are the same? Quote please, if You're not a troll.
>I said that _they_ _can_ _be_ _used_ _the_ _same_ _way_ in the case
>mentioned above - running scripts from commandline.
>And without checking the SAPI used to run a script, You can't, in fact, be
>sure that You are running under CLI or CGI interface. Other way, You can't (in
>script) be sure You're running from commandline or started from server.
>I saw many posts on forums discussing that "PHP is running almost fine on my
>server but some glitches..." and that was the case of using CLI instead of CGI
>executable.
>If You want to say that it is impossible, good luck... but life isn't loose
>it's colors just because You're blind.

>>>>CGI is not run from the command line.
I've showed the test where it does. Test please before writing.

>>No. All you've done is run the CGI executable from the command line.
You cannot run a CGI program from the command line.

>Testcase, please.

RTFM. I'm not in the business of giving you free training.

Then, I suppose You have nothing to confirm Your words. What means, it is only
words. Words are cheap. PHP is not a religion, is a programming language.

Learn what CGI is and you have your answer. Or, I will provide all the
information you want at my regular consulting rates.

I have information, and I provide a testcase confirming it.
You said that You have something other but You gave only words confirming Your
opinion. Can I be sure that You're right?
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[Jerry Stuckle]

AnrDaemon wrote:

Greetings, Jerry Stuckle.
In reply to Your message dated Monday, December 10, 2007, 23:20:11,

>>>>>>>>Your statement "they are different because they are intended to use
>>>>in different way" is silly.
>>>>>
>>>Nope. CGI is not the same as CLI. And if you understood that you
>>>wouldn't make the stupid claim that they are.
>>Where I said that they are the same? Quote please, if You're not a troll.
>>I said that _they_ _can_ _be_ _used_ _the_ _same_ _way_ in the case
>>mentioned above - running scripts from commandline.
>>And without checking the SAPI used to run a script, You can't, in fact, be
>>sure that You are running under CLI or CGI interface. Other way, You can't (in
>>script) be sure You're running from commandline or started from server.
>>I saw many posts on forums discussing that "PHP is running almost fine on my
>>server but some glitches..." and that was the case of using CLI instead of CGI
>>executable.
>>If You want to say that it is impossible, good luck... but life isn't loose
>>it's colors just because You're blind.

>>>>>CGI is not run from the command line.
I've showed the test where it does. Test please before writing.

>>>No. All you've done is run the CGI executable from the command line.
You cannot run a CGI program from the command line.

>>Testcase, please.

>RTFM. I'm not in the business of giving you free training.

Then, I suppose You have nothing to confirm Your words. What means, it is only
words. Words are cheap. PHP is not a religion, is a programming language.

>Learn what CGI is and you have your answer. Or, I will provide all the
information you want at my regular consulting rates.

I have information, and I provide a testcase confirming it.
You said that You have something other but You gave only words confirming Your
opinion. Can I be sure that You're right?

As I said. RTFM. Or, if you want me to teach you, pay my normal
consulting rates.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Ojas]

On Dec 9, 7:51 pm, Jerry Stuckle <[e-mail]:

Ojaswrote:

Hi!,

NC you have provided the list of all the available PHP SAPI but forgot
to mention when we can expect which is under existence?

Probably because that cannot be known in advance.

Also, this is very high level of intrusion being able to access the
site using CURL and socket. I can remember i access one of the site
using sockets to get the result of an particular operation to be shown
on interface of one of my project without even giving reference or
link to the output generator, of-course i would not like someone else
be able to do the same on my site. In that case how can i stop this
type of accessing?

Ojas.

That's the way the web works, and there's no way to stop it. If you
don't like it, don't use HTML. Create java applets, for instance,
instead. You'll lose a fair number of customers, but others won't be
able to use cURL. Or better yet, don't even put it on the web.

Of course, you'll lose all of the search engines, also. But heck -
you'll have your security.

Good comments.

>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Ojas

[Ojas]

On Dec 9, 11:32 pm, NC <[e-mail]:

On Dec 9, 5:22 am,Ojas<[e-mail]:

On Dec 7, 8:54 pm, NC <[e-mail]:

- aolserver
- activescript
- apache
- cgi-fcgi
- cgi
- isapi
- nsapi
- phttpd
- roxen
- java_servlet
- thttpd
- pi3web
- apache2filter
- caudium
- apache2handler
- tux
- webjames
- cli
- embed
- milter

NC you have provided the list of all the available PHP SAPI but
forgot to mention when we can expect which is under existence?

The names are fairly descriptive. "aolserver", for example, means
that PHP is running under AOL Server.

Also, this is very high level of intrusion being able to access
the site using CURL and socket.

Er, and how do you think browsers access them? Through the same
sockets...

I can remember i access one of the site using sockets to get
the result of an particular operation to be shown on interface
of one of my project without even giving reference or link to
the output generator, of-course i would not like someone else
be able to do the same on my site. In that case how can i stop
this type of accessing?

You really can't. A socket program can be written to do anything a
browser does. About the only thing you can do is to obfuscate the
server-side logic by complicating the client side through the use of
Flash, Java applets, ActiveX controls, or AJAX.

Cheers,
NC

Hi NC,

I am not asking for the description, what i am wishing to know the
conditions under which these PHP SAPI will be under existence. For ex.
as we discussed earlier, when accessing script under command prompt,
we got the "cli" and when accessing under the browser, we got the
"apache2handler" respectively as the PHP SAPI. When the other ones are
expected?

Ojas

[Ojas]

On Dec 9, 11:32 pm, NC <[e-mail]:

On Dec 9, 5:22 am,Ojas<[e-mail]:

On Dec 7, 8:54 pm, NC <[e-mail]:

- aolserver
- activescript
- apache
- cgi-fcgi
- cgi
- isapi
- nsapi
- phttpd
- roxen
- java_servlet
- thttpd
- pi3web
- apache2filter
- caudium
- apache2handler
- tux
- webjames
- cli
- embed
- milter

NC you have provided the list of all the available PHP SAPI but
forgot to mention when we can expect which is under existence?

The names are fairly descriptive. "aolserver", for example, means
that PHP is running under AOL Server.

Also, this is very high level of intrusion being able to access
the site using CURL and socket.

Er, and how do you think browsers access them? Through the same
sockets...

I can remember i access one of the site using sockets to get
the result of an particular operation to be shown on interface
of one of my project without even giving reference or link to
the output generator, of-course i would not like someone else
be able to do the same on my site. In that case how can i stop
this type of accessing?

You really can't. A socket program can be written to do anything a
browser does. About the only thing you can do is to obfuscate the
server-side logic by complicating the client side through the use of
Flash, Java applets, ActiveX controls, or AJAX.

Cheers,
NC

And yes i used AJAX for the same.

Ojas

[Ojas]

On Dec 11, 2:26 am, Jerry Stuckle <[e-mail]:

AnrDaemon wrote:

Greetings, Jerry Stuckle.
In reply to Your message dated Monday, December 10, 2007, 23:20:11,

>>>>>>>Your statement "they are different because they are intended to use
>>>in different way" is silly.

>>>>>>Nope. CGI is not the same as CLI. And if you understood that you
>>wouldn't make the stupid claim that they are.
>Where I said that they are the same? Quote please, if You're not a troll.
>I said that _they_ _can_ _be_ _used_ _the_ _same_ _way_ in the case
>mentioned above - running scripts from commandline.
>And without checking the SAPI used to run a script, You can't, in fact, be
>sure that You are running under CLI or CGI interface. Other way, You can't (in
>script) be sure You're running from commandline or started from server.
>I saw many posts on forums discussing that "PHP is running almost fine on my
>server but some glitches..." and that was the case of using CLI instead of CGI
>executable.
>If You want to say that it is impossible, good luck... but life isn't loose
>it's colors just because You're blind.

>>>>CGI is not run from the command line.
I've showed the test where it does. Test please before writing.

>>No. All you've done is run the CGI executable from the command line.
You cannot run a CGI program from the command line.

>Testcase, please.

RTFM. I'm not in the business of giving you free training.

Then, I suppose You have nothing to confirm Your words. What means, it is only
words. Words are cheap. PHP is not a religion, is a programming language.

Learn what CGI is and you have your answer. Or, I will provide all the
information you want at my regular consulting rates.

I have information, and I provide a testcase confirming it.
You said that You have something other but You gave only words confirming Your
opinion. Can I be sure that You're right?

As I said. RTFM. Or, if you want me to teach you, pay my normal
consulting rates.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Please stop this type of discussion here. We are here to discuss and
share the information we have and not for arguing this way. If someone
is not willing for something, don't force for that. This all lead to
corrupting the very good effect we have until now.

Also please don't ask for the consultancy rates.

Thanks,
Ojas.

[Jerry Stuckle]

Ojas wrote:

>
Please stop this type of discussion here. We are here to discuss and
share the information we have and not for arguing this way. If someone
is not willing for something, don't force for that. This all lead to
corrupting the very good effect we have until now.

Also please don't ask for the consultancy rates.

Thanks,
Ojas.

I don't know about you, but I'm here to help people with their problems.
I'm not here to RTFM to someone.

But in addition, when someone provides incorrect information I will
correct them on it. Not for their sake - but so that of others reading
the thread understand the information is incorrect.

And don't worry - he wouldn't like my consulting rates.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Norman Peelman]

Ojas wrote:

On Dec 9, 11:32 pm, NC <[e-mail]:

>On Dec 9, 5:22 am,Ojas<[e-mail]:

>>On Dec 7, 8:54 pm, NC <[e-mail]:
- aolserver
- activescript
- apache
- cgi-fcgi
- cgi
- isapi
- nsapi
- phttpd
- roxen
- java_servlet
- thttpd
- pi3web
- apache2filter
- caudium
- apache2handler
- tux
- webjames
- cli
- embed
- milter
NC you have provided the list of all the available PHP SAPI but
forgot to mention when we can expect which is under existence?

The names are fairly descriptive. "aolserver", for example, means
that PHP is running under AOL Server.

>>Also, this is very high level of intrusion being able to access
the site using CURL and socket.

Er, and how do you think browsers access them? Through the same
sockets...

>>I can remember i access one of the site using sockets to get
the result of an particular operation to be shown on interface
of one of my project without even giving reference or link to
the output generator, of-course i would not like someone else
be able to do the same on my site. In that case how can i stop
this type of accessing?

You really can't. A socket program can be written to do anything a
browser does. About the only thing you can do is to obfuscate the
server-side logic by complicating the client side through the use of
Flash, Java applets, ActiveX controls, or AJAX.

Cheers,
NC

Hi NC,

I am not asking for the description, what i am wishing to know the
conditions under which these PHP SAPI will be under existence. For ex.
as we discussed earlier, when accessing script under command prompt,
we got the "cli" and when accessing under the browser, we got the
"apache2handler" respectively as the PHP SAPI. When the other ones are
expected?

Ojas

I kind of thought they were somewhat self-explanatory. But, just
googling most of those terms will turn up exactly what they are (mostly
http servers). Just google '<term>' or 'php' '<term>' (no quotes) and
you will find out. Took me two minutes. If it wasn't the first result,
it was on the first page of results.

---
Norm

[Steve]

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Nq******************************@comcast.com. ..

Ojas wrote:

>>
Please stop this type of discussion here. We are here to discuss and
share the information we have and not for arguing this way. If someone
is not willing for something, don't force for that. This all lead to
corrupting the very good effect we have until now.

FOAD. this is usenet provided by the internet. mediate your personal life!

>Also please don't ask for the consultancy rates.

expensive is relative...but as for the priciple here, i wouldn't give 0.02
USD for the counter argument attempted. not just because of form and lack of
support, but because it shows itself to be addressing something not even
germain to what it counters.

I don't know about you, but I'm here to help people with their problems.
I'm not here to RTFM to someone.

jerry, you've missed his point. it's not about *how* php is executed as cgi,
module, cli or any combination from the command-line or the web server. it's
completely about being *able* to use any combination of the
aforementioned...and being able to tell, as the script writer, what
environment the code is being run under.

as for what he said specifically, yes, you can obviously run a script from
the command-line as cgi. i'm not sure what you allude to by saying "CGI is
not run from the command line" and the notion that cgi *can not* be run from
the command line..or that "The processing and options
are not the same". who cares about the options in this argument...and the
external environment may treat php differently, but, in no way is the code
in a php script interpreted differently.

it would be good if you would take a moment and be less vague about those
points.

But in addition, when someone provides incorrect information I will
correct them on it. Not for their sake - but so that of others reading
the thread understand the information is incorrect.

then do it methodically. that means you make a counter argument and
demonstrate it factually...rather than just saying 'it's this way' just
because you say it is. you not only failed to do so in this case, but warn
of insuing fees being owed were you to do so.

sorry, if you wanted to win the current debate, you'd be more than willing
to give support for your posit(s). as it is, you cannot counter. he is
absolutely right. you *can* run php as cgi from the command-line. it is done
all the time. your counter *can only be* that is can NOT. your argument that
cgi is *normally* initiated via a web server has nothing to do with the
point. the original point is "can"...who cares about "normally". that's
where you missed it.

And don't worry - he wouldn't like my consulting rates.

don't 'bow up' jerry. he made a good point and provided proof. all he asked
of you was for you to provide proof for your counter argument. the only
problem is, you've missed his point outright. this is a trend i've
experienced with you before. you know your stuff, however, you most often
become argumentative and defensive not when you don't understand php, but
when you clearly don't understand the point someone else is making. it seems
to me that sometimes, you either aren't listening or have it in your mind
that someone is trying to prove you wrong just to get at you...and you gloss
over what they've got to say.

[Jerry Stuckle]

Steve wrote:

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Nq******************************@comcast.com. ..

>Ojas wrote:

>>Please stop this type of discussion here. We are here to discuss and
share the information we have and not for arguing this way. If someone
is not willing for something, don't force for that. This all lead to
corrupting the very good effect we have until now.

FOAD. this is usenet provided by the internet. mediate your personal life!

>>Also please don't ask for the consultancy rates.

expensive is relative...but as for the priciple here, i wouldn't give 0.02
USD for the counter argument attempted. not just because of form and lack of
support, but because it shows itself to be addressing something not even
germain to what it counters.

>I don't know about you, but I'm here to help people with their problems.
I'm not here to RTFM to someone.

jerry, you've missed his point. it's not about *how* php is executed as cgi,
module, cli or any combination from the command-line or the web server. it's
completely about being *able* to use any combination of the
aforementioned...and being able to tell, as the script writer, what
environment the code is being run under.

No, I didn't miss his point at all. You can run a CLI program using the
CGI executable - but that doesn't mean it's a CGI program. It's just a CLI.

CGI programs have additional things you can do. A true CGI will not run
from the CLI.

as for what he said specifically, yes, you can obviously run a script from
the command-line as cgi. i'm not sure what you allude to by saying "CGI is
not run from the command line" and the notion that cgi *can not* be run from
the command line..or that "The processing and options
are not the same". who cares about the options in this argument...and the
external environment may treat php differently, but, in no way is the code
in a php script interpreted differently.

CGI programs interface with the web server (typically). When you run
from the command line, these options aren't available because you don't
have a HTTPD session (not PHP session) available.

it would be good if you would take a moment and be less vague about those
points.

It's very obvious if you understand what a CGI program is. Obviously he
does not. And I'm not here to give give him a free tutorial on it.

>But in addition, when someone provides incorrect information I will
correct them on it. Not for their sake - but so that of others reading
the thread understand the information is incorrect.

then do it methodically. that means you make a counter argument and
demonstrate it factually...rather than just saying 'it's this way' just
because you say it is. you not only failed to do so in this case, but warn
of insuing fees being owed were you to do so.

I'm sorry, I'm not going to argue with an idiot.

sorry, if you wanted to win the current debate, you'd be more than willing
to give support for your posit(s). as it is, you cannot counter. he is
absolutely right. you *can* run php as cgi from the command-line. it is done
all the time. your counter *can only be* that is can NOT. your argument that
cgi is *normally* initiated via a web server has nothing to do with the
point. the original point is "can"...who cares about "normally". that's
where you missed it.

I'm not trying to win any debate. But I'm not giving free training, either.

>And don't worry - he wouldn't like my consulting rates.

don't 'bow up' jerry. he made a good point and provided proof. all he asked
of you was for you to provide proof for your counter argument. the only
problem is, you've missed his point outright. this is a trend i've
experienced with you before. you know your stuff, however, you most often
become argumentative and defensive not when you don't understand php, but
when you clearly don't understand the point someone else is making. it seems
to me that sometimes, you either aren't listening or have it in your mind
that someone is trying to prove you wrong just to get at you...and you gloss
over what they've got to say.

The only "point" he made is that he can run a CLI from the command line
with the CGI executable. He claimed that made it a CGI program. It
does not.

I didn't miss that point, but you obviously did.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Steve]

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Vt******************************@comcast.com. ..

Steve wrote:

>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Nq******************************@comcast.com ...

>>Ojas wrote:

Please stop this type of discussion here. We are here to discuss and
share the information we have and not for arguing this way. If someone
is not willing for something, don't force for that. This all lead to
corrupting the very good effect we have until now.

FOAD. this is usenet provided by the internet. mediate your personal
life!

>>>Also please don't ask for the consultancy rates.

expensive is relative...but as for the priciple here, i wouldn't give
0.02 USD for the counter argument attempted. not just because of form and
lack of support, but because it shows itself to be addressing something
not even germain to what it counters.

>>I don't know about you, but I'm here to help people with their problems.
I'm not here to RTFM to someone.

jerry, you've missed his point. it's not about *how* php is executed as
cgi, module, cli or any combination from the command-line or the web
server. it's completely about being *able* to use any combination of the
aforementioned...and being able to tell, as the script writer, what
environment the code is being run under.

No, I didn't miss his point at all. You can run a CLI program using the
CGI executable - but that doesn't mean it's a CGI program. It's just a
CLI.

so, the distinction you made earlier - that there's a reason there are two
executables for *php*, one for cgi and one for cli - is an argument you now
take with yourself?

please note that a quick search of the net reveals links like:

http://www.sitepoint.com/article/php-command-line-1/3

when the page comes up, just search for 'compatibility' toward the bottom.
then, read the whole article, as i think you need a refresher. see jerry,
this is where it helps to support yourself.

CGI programs have additional things you can do. A true CGI will not run
from the CLI.

is this some theoretical 'true cgi'. we're talking about php. and in php,
regardless of what your relative definition of truth is, you can run pure
cgi and even mimic most of cli features.

>as for what he said specifically, yes, you can obviously run a script
from the command-line as cgi. i'm not sure what you allude to by saying
"CGI is not run from the command line" and the notion that cgi *can not*
be run from the command line..or that "The processing and options
are not the same". who cares about the options in this argument...and the
external environment may treat php differently, but, in no way is the
code in a php script interpreted differently.

CGI programs interface with the web server (typically). When you run from
the command line, these options aren't available because you don't have a
HTTPD session (not PHP session) available.

really? i didn't know that at all. hmmmf. again, who cares about typically.
you can run php cgi from the command line. that's the claim. you say it
can't be done. whatever 'options' you vaguely content aren't there are
beside the claim and are not part of this discussion. this is typical
'jerry'. stick to disproving THE CLAIM, not addressing things you'd like
whilst thinking you're offering a counter.

>it would be good if you would take a moment and be less vague about those
points.

It's very obvious if you understand what a CGI program is. Obviously he
does not. And I'm not here to give give him a free tutorial on it.

i do. seems to me he does too. and as for your tutorial on this subject, i'm
afraid free would be too much of a charge. ever think of working for the
government? you'd be great at supplying mis-information.

>>But in addition, when someone provides incorrect information I will
correct them on it. Not for their sake - but so that of others reading
the thread understand the information is incorrect.

then do it methodically. that means you make a counter argument and
demonstrate it factually...rather than just saying 'it's this way' just
because you say it is. you not only failed to do so in this case, but
warn of insuing fees being owed were you to do so.

I'm sorry, I'm not going to argue with an idiot.

he's not an idiot, nor is anyone else here. you press it though when you
talk out of your ass. give proof that php cgi can NOT be run from the
command line. and when your efforts fail, then address the OP by helping him
be able to determine what process initiated the script in question.

stay on task jerry.

>sorry, if you wanted to win the current debate, you'd be more than
willing to give support for your posit(s). as it is, you cannot counter.
he is absolutely right. you *can* run php as cgi from the command-line.
it is done all the time. your counter *can only be* that is can NOT. your
argument that cgi is *normally* initiated via a web server has nothing to
do with the point. the original point is "can"...who cares about
"normally". that's where you missed it.

I'm not trying to win any debate.

obviously. i wonder what a good debate from you would look like.

>But I'm not giving free training, either.

again, on this question, free is overpriced.

>>And don't worry - he wouldn't like my consulting rates.

don't 'bow up' jerry. he made a good point and provided proof. all he
asked of you was for you to provide proof for your counter argument. the
only problem is, you've missed his point outright. this is a trend i've
experienced with you before. you know your stuff, however, you most often
become argumentative and defensive not when you don't understand php, but
when you clearly don't understand the point someone else is making. it
seems to me that sometimes, you either aren't listening or have it in
your mind that someone is trying to prove you wrong just to get at
you...and you gloss over what they've got to say.

The only "point" he made is that he can run a CLI from the command line
with the CGI executable. He claimed that made it a CGI program. It does
not.

I didn't miss that point, but you obviously did.

WOW !!! here, i'll post his point here to show how far from the *point* you
are...

<quote>
You forgot that PHP-CGI *IS* a commandline executable intended to deal with
pipelined I/O from/to server.
And You still can use it instead of CLI (either knowing that or by
accident).
</quote>

now, where exactly does he say he can run a cli from the command-line using
the cgi exe? notice the *only* mention of cli here is that cgi can be used
*instead of* cli. nothing there about cli via cgi.

finally, jerry, i find it utterly laughable that you state:

<quote>
If it's using php-cgi, then it's not started from the command line, is it?
</quote>

yet then fail to note your overlooked admission that it, in fact, can be:

<quote>
Ah, but there are differences. And much more than your little --help
commands show. All they have is the command line options.
</quote>

please pay particularly close attention to your last sentence. and for good
measure, look at the first sentence. that's a jerry-ism. who gives a rats
ass about 'differences'? his POINT was that cgi can be run on the command
line as can cli...and that relates to the need of the op to be able to tell
the environment under which his script is running. the jerry-ism is your
inability to ever offer a direct counter. you tend to build strawmen all
around and think lighting them will make other observers watch the spectacle
whilst forgetting everything else.

two of us aren't buying it.

[Ojas]

On Dec 11, 3:43 pm, Jerry Stuckle <[e-mail]:

Ojas wrote:

Please stop this type of discussion here. We are here to discuss and
share the information we have and not for arguing this way. If someone
is not willing for something, don't force for that. This all lead to
corrupting the very good effect we have until now.

Also please don't ask for the consultancy rates.

Thanks,
Ojas.

I don't know about you, but I'm here to help people with their problems.
I'm not here to RTFM to someone.

But in addition, when someone provides incorrect information I will
correct them on it. Not for their sake - but so that of others reading
the thread understand the information is incorrect.

And don't worry - he wouldn't like my consulting rates.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Its good that you are willing and wishing to help out others not just
with information but also with correction.

Ojas

[Jerry Stuckle]

Steve wrote:

"Jerry Stuckle" <js*******@attglobal.netwrote in message

Complete shite snipped.

Steve, I told you what the difference is. I really don't give a damn if
you agree with it or not.

You need to learn what CGI is, also. Just running a program form the
CGI executable doesn't make it a CGI program. I tried to explain the
difference.

Now go take your head out of your ass and RTFM. Trying to help you is
like trying to teach a pig to sing. It wastes your time and leaves you
stinking.

I let you suck me into trying to teach a pig to sing once. But I'm
stopping it right near.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Steve]

"Ojas" <co*********@gmail.comwrote in message
news:64**********************************@y5g2000h sf.googlegroups.com...

On Dec 11, 3:43 pm, Jerry Stuckle <[e-mail]:

>Ojas wrote:

Its good that you are willing and wishing to help out others not just
with information but also with correction.

correction? yes, if he could actually do that, that would be good. were i
you, i'd read the link that i posted. it shows different ways to detect
whether a script is running via cgi or cli. the presence or absence of
certain features will be a good indicator of whether or not it was kicked
off via a http request or the command prompt. it also shows jerry's
'correction' to be an absolute sham and a terrible falsehood.

[Jerry Stuckle]

Steve wrote:

"Ojas" <co*********@gmail.comwrote in message
news:64**********************************@y5g2000h sf.googlegroups.com...

>On Dec 11, 3:43 pm, Jerry Stuckle <[e-mail]:

>>Ojas wrote:

>Its good that you are willing and wishing to help out others not just
with information but also with correction.

correction? yes, if he could actually do that, that would be good. were i
you, i'd read the link that i posted. it shows different ways to detect
whether a script is running via cgi or cli. the presence or absence of
certain features will be a good indicator of whether or not it was kicked
off via a http request or the command prompt. it also shows jerry's
'correction' to be an absolute sham and a terrible falsehood.

And you are completely full of shit. Just running a script with the CGI
executable does not make it a CGI script. But you're too dense to
understand that.

But that's not at all unusual for you, Steve. You never were very smart
- or able to understand anything requiring words of more than 1 syllable.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Steve]

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Ep******************************@comcast.com. ..

Steve wrote:

>"Ojas" <co*********@gmail.comwrote in message
news:64**********************************@y5g2000 hsf.googlegroups.com...

>>On Dec 11, 3:43 pm, Jerry Stuckle <[e-mail]:
Ojas wrote:

>>Its good that you are willing and wishing to help out others not just
with information but also with correction.

correction? yes, if he could actually do that, that would be good. were i
you, i'd read the link that i posted. it shows different ways to detect
whether a script is running via cgi or cli. the presence or absence of
certain features will be a good indicator of whether or not it was kicked
off via a http request or the command prompt. it also shows jerry's
'correction' to be an absolute sham and a terrible falsehood.

And you are completely full of shit. Just running a script with the CGI
executable does not make it a CGI script. But you're too dense to
understand that.

i'm dense? hey dumbass, let's do this in steps. first, let's establish
whether or not you can even run cgi from the command line. wait, you can.
wait, that was the only point being made. hmmm, so how does the form of the
script become part of the discussion? it doesn't? oh yeah, that's right.

get it now?

But that's not at all unusual for you, Steve. You never were very smart -
or able to understand anything requiring words of more than 1 syllable.

he, he, he. there's the other jerry-ism i expect to see at this
juncture...ad-homs...where 90% of jerry's response is ad-hom, jerry is both
losing his arguments and about to bail on the conversation to save face. i
suppose i'll see the latter in your next installment. and i can't say it
will be too soon.

sticks-and-stones, jerry. grow up. for that to hurt my feelings, i'd have to
elevate my estimation of you higher than at least a toad. as it is, you're
about mosquito level...and just as annoying.