which page called the URL in error?

[a_design_interactive]

i'm guessing off of the top of my head that this is something of how it is done...

page sends a user to another page. an error occurs! lets tell the user some info about that-- specifically, let's tell the user what was the name of that page which sent them to that URL, ultimately resulting in that error.

i've tried just a simple echo phpinfo();, but i don't think what i'm looking for is in there-- unless i just can't see it -- because i'm calling the page directly, and not via any previous, POSTing page.

my first thought was _SERVER["REQUEST_URI"] , but that doesn't seem to do it

anyone out there know what i'm looking for? if Apache didn't use "funny" code, i'd probably be good enough to just steal it out of a 404, but-- i don't think that will work... would it?

thanks!!

[Twey]

$_SERVER['HTTP_REFERER'] should be what you want.

[a_design_interactive]

hey there, Twey. thank you for your reply!

yes, i agree w/ you about that solution... only problem is, what i've read here at PHP.NET is what troubles me:
http://php.net/manual/en/reserved.va...riables.server

i suppose part of the "mystique" of this issue, to me since i became aware of these nifty little buggers, it surrounds this elusive "is it an apache server?" is their user agent going to read it as you expect?...

so, this is why i was thinking that perhaps-- there was a better, more "pro" way of doing it-- for lack of a better term. (ie. "oh, that's just some newbie fooling around w/ the SERVER variables... he'll learn someday to do it with X Y Z instead as a much more secure choice... but this will be okay for him now")

so, considering that fairly heavy "BUT" in the fact that "you may use 'HTTP_REFERER' for these and those, BUT don't be surprised if it doesn't work, or you don't get what you want", what then might we do in order to feel more comfortable about using such a function as 'HTTP_REFERER?
if it is in fact then such a subjectively accurate server variable, is there any "rule of thumb" practice in place, generally spread among the ranks, which is used to handle this anomaly?

OR, would we be more Progressive to think, "Well, you really shouldn't need that anyway. because, what you should be doing, is avoiding this situation altogether by way of .... "

thank you for humoring me!! of course i can accept the simple "no. this is it. there is nothing else" . it just happens to be an interest of mine. i don't mean to pull you down w/ me.

[mwinter]

so, this is why i was thinking that perhaps-- there was a better, more "pro" way of doing it-- for lack of a better term.

Not really. There are alternatives, but I don't think they're worth the effort. It depends on why you're doing this.

The first, very nasty alternative, is to include the URL of the referring page (or at least some unique identifier) in the query string when generating links to other documents. The second, over-the-top method is to establish a session and track the user's location on the server.

If you must do this, and it must work reliably, those are your options (unless someone else has more).

so, considering that fairly heavy "BUT" in the fact that "you may use 'HTTP_REFERER' for these and those, BUT don't be surprised if it doesn't work, or you don't get what you want", what then might we do in order to feel more comfortable about using such a function as 'HTTP_REFERER?

Check it's value before using it. Some people configure their browsers or a proxy to strip the header so there won't be a Referer (sic) header to use at all. Some may spoof a value. In the latter case, you can start by checking that it's an absolute URL that contains your domain. You could go further, if you wanted to, by checking that the path refers to a document that might lead to the current location, of if it's just well-spoofed.

if it is in fact then such a subjectively accurate server variable, is there any "rule of thumb" practice in place, generally spread among the ranks, which is used to handle this anomaly?

It's not really an anomaly. The general rule of thumb is to never trust the user. That doesn't apply to all HTTP headers, but it does to User-Agent and Referer, and also to all form input (including things that you might like to consider preset; hidden values, select element options, etc.).

Mike

[Twey]

The key sentence is

It depends on why you're doing this.

If it's just a convenience mechanism, there's no problem if it doesn't work occasionally (especially if you check the header so it degrades gracefully and doesn't show "We're sorry, but there appears to be an invalid link on the page (none)."). If it's mission-critical, you might want to think about some other way of accomplishing it.