PHP_SELF, $_SERVER, etc

On Apr 3, 7:22 pm, eholz1 wrote:
> I suppose there is a way to add the PHP_SELF from the calling page
> using $_SERVER['PHP_SELF'] to the query string.  I was wondering if
> there is some "default" way the destination page (view.php) would know
> what page the image ref came from.
>
> I would like to use the ref to the page that sent the image path for a
> "back" button from the view.php page.  Or...
>
> What is the better way to do this?
>

The information can be detected using this variable.

Server variables: $_SERVER 'HTTP_REFERER'
The address of the page (if any) which referred the user agent to the
current page. This is set by the user agent. Not all user agents will
set this, and some provide the ability to modify HTTP_REFERER as a
feature. In short, it cannot really be trusted.
 >> Stay informed about: PHP_SELF, $_SERVER, etc 

On Apr 4, 3:45 am, Utopar wrote:
> On Apr 3, 7:22 pm, eholz1 wrote:
>
> > I suppose there is a way to add the PHP_SELF from the calling page
> > using $_SERVER['PHP_SELF'] to the query string. I was wondering if
> > there is some "default" way the destination page (view.php) would know
> > what page the image ref came from.
>
> > I would like to use the ref to the page that sent the image path for a
> > "back" button from the view.php page. Or...
>
> > What is the better way to do this?
>
> The information can be detected using this variable.
>
> Server variables: $_SERVER 'HTTP_REFERER'
> The address of the page (if any) which referred the user agent to the
> current page. This is set by the user agent. Not all user agents will
> set this, and some provide the ability to modify HTTP_REFERER as a
> feature. In short, it cannot really be trusted.

Hello Again,

As always thanks for the information. I kinda favor server side code,
as opposed to the javascript solution. But...

Server variables: $_SERVER 'HTTP_REFERER'
> The address of the page (if any) which referred the user agent to the
> current page. This is set by the user agent. Not all user agents will
> set this, and some provide the ability to modify HTTP_REFERER as a
> feature. In short, it cannot really be trusted.

worries me slightly, due to the last statement "cannot really be
trusted" - that is like washington D.C.!!! I will try the $_server
variable out.

Thanks for the good info.

eholz1
 >> Stay informed about: PHP_SELF, $_SERVER, etc 

..oO(Sylvain SF)

>eholz1 wrote on 04/04/2008 01:22:
>
>> I would like to use the ref to the page that sent the image path for a
>> "back" button from the view.php page. Or...
>> What is the better way to do this?
>
>hmm, what about: <a href="javascript:history.go(-1)">Back</a>

Ugly and unreliable.

>I always prefer solutions that use visitor CPU instead of server's CPU
>but it's just my pref.

Yes, but JS is optional. Server-side code works always.

Micha
 >> Stay informed about: PHP_SELF, $_SERVER, etc 

Michael Fesser wrote on 04/04/2008 11:58:
>> hmm, what about: <a href="javascript:history.go(-1)">Back</a>
> Ugly and unreliable.

don't you trust your script engine ? change your script engine.

> Yes, but JS is optional.

(and in case available on 99% of the browsers).
and ? a computer also is optional, a browser is optional, a brain
is may be optional for web site visitor. you believe a basic link
should take into account all these optional features ?

> Server-side code works always.

if it doesn't rely on client information. here it's the case.
a server-side code will *not* always work, and thus is not
reliable.

btw, thanks for the nice exchange.

Sylvain.
 >> Stay informed about: PHP_SELF, $_SERVER, etc 

"Sylvain SF" wrote in message

> Michael Fesser wrote on 04/04/2008 11:58:
> >> hmm, what about: <a href="javascript:history.go(-1)">Back</a>
> > Ugly and unreliable.
>
> don't you trust your script engine ? change your script engine.

It's not the script engine we don't trust. It's everyone else's scripts we
don't trust.

> > Yes, but JS is optional.
> ...
 >> Stay informed about: PHP_SELF, $_SERVER, etc 

The HTTP_REFERER is worst option. Numerous firewalls, and sometimes
proxies, don't send that data.
 >> Stay informed about: PHP_SELF, $_SERVER, etc 

..oO(Sylvain SF)

>Michael Fesser wrote on 04/04/2008 11:58:
>>> hmm, what about: <a href="javascript:history.go(-1)">Back</a>
>> Ugly and unreliable.
>
>don't you trust your script engine ? change your script engine.

It's not about a scripting engine, but about ugly code. The javascript:
pseudo-protocol is just stupid, the entire link appears as non-working
to users without JS and even if it works it might throw the user back to
a completely unrelated page. Going back in the browser history is not
what the OP wants.

>> Yes, but JS is optional.
>
>(and in case available on 99% of the browsers).

Wrong. Just because most modern browsers support JS doesn't mean that
it's always enabled. And then there's a whole bunch of non-JS user
agents, for example search engines.

>> Server-side code works always.
>
>if it doesn't rely on client information. here it's the case.
>a server-side code will *not* always work, and thus is not
>reliable.

Wrong again. If it's done on the server, it's completely independent
from the client's capabilities, environment and network, whereas
JavaScript always depends on what the client is able to do and if he
will be able to execute it at all.

Micha
 >> Stay informed about: PHP_SELF, $_SERVER, etc 

Michael Fesser wrote on 05/04/2008 12:09:

something likes "wrong, wrong, wrong, ad libitium".

> It's not about a scripting engine, but about ugly code. [...]

and "ugly, ugly, ugly, ad libitium".

with so many strong arguments, I'm really puzzled to answer.

> for example search engines.

irrelevant.

> Wrong again. If it's done on the server, it's completely independent
> from the client's capabilities, [...]

of course, when server tries to get *information sent by the client*,
it's "completely [client] independent".

thank for all these "true, true, true, nice, nice, nice" points.

Sylvain.
 >> Stay informed about: PHP_SELF, $_SERVER, etc 

..oO(Sylvain SF)

>Michael Fesser wrote on 05/04/2008 12:09:
>
>something likes "wrong, wrong, wrong, ad libitium".
>
>> It's not about a scripting engine, but about ugly code. [...]
>
>and "ugly, ugly, ugly, ad libitium".
>
>with so many strong arguments, I'm really puzzled to answer.

Doesn't matter. You're just trolling anyway.

>> for example search engines.
>
>irrelevant.

If you think.

>> Wrong again. If it's done on the server, it's completely independent
>> from the client's capabilities, [...]
>
>of course, when server tries to get *information sent by the client*,
>it's "completely [client] independent".
>
>thank for all these "true, true, true, nice, nice, nice" points.

Thanks for no points at all from you. Now please play somewhere else.

EOD
Micha
 >> Stay informed about: PHP_SELF, $_SERVER, etc 

Michael Fesser wrote on 05/04/2008 19:29:
>
> Thanks for no points at all from you. Now please play somewhere else.

Dear Michael, apparently you want present yourself like these guys
that do consider a ng as their own private play space 'cause they
did post before someone else. great I don't care.

Apparently, you also want to deny that a *client* item is not a server
item, calling such fact "troll", great.

FYI, I'm not "playing" nor I consider that ng shall be the place where
one has to show that his own is bigger than others.

thank for this useless exchange, you were wrong AND it doesn't matter.

Sylvain.
 >> Stay informed about: PHP_SELF, $_SERVER, etc