PHP_SELF, $_SERVER, etc

Hello news group,

This is a dumb question. Sorry. I would like to pass the name of the
"page",
along with some $_REQUEST variables.

I used the $_REQUEST to send and image name (with path) to a page that
displays the image referred to in the query string "view.php?
image=nicepix.jpg&p=1".

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?

Thanks

eholz1

eholz1 wrote on 04/04/2008 01:22:
> Hello news group,

hello,

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

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

Sylvain.

..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

On Apr 3, 7:22*pm, eholz1 <ewh...@gmail.com> 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.

On Apr 4, 3:45 am, Utopar <JeffMer...@gmail.com> wrote:
> On Apr 3, 7:22 pm, eholz1 <ewh...@gmail.com> 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

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.

"Sylvain SF" <sylvain@boiteaspam.info> wrote in message
news:47f68423$0$865$ba4acef3@news.orange.fr...
> 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.
> ...

The HTTP_REFERER is worst option. Numerous firewalls, and sometimes
proxies, don't send that data.

..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

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.