This content has been marked as final. Show 10 replies
Very useful - will definetly make use of this Vikas :)
Beware the following from RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1":
"Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent."
Some people, browsers, firewalls, and proxies choose not to send the Referer field, leading to a blank HTTP_REFERER.
One can accomplish the same effect by setting the application item in the branch leading to the page. It's a hassle, but it avoids a dependence on a browser feature that is not guaranteed to be there.
branch leading to the page
Thanks for the clarification but as I said earlier this is when "the navigation is done using links/lists/column links". In these cases, there is no branch, the page is navigated to using a link and the calling page information is available only in that Referer field (I think, feel free to correct me if I am wrong).
For cases where you know what page you are on (e.g., a column link on a report on a particular page), you can hardcode the current page number into the link or URL if you prefer simple and direct. In other cases or when you prefer generality, you can use APP_PAGE_ID.
Yes, I realize that and was merely offering an alternative "automated" method that would obviate the need to "remember" to stick in P1_CALLING_PAGE:&APP_PAGE_ID. every time you link to Page 1. In other words, every page that is navigated to using a link, no matter from whereever in the app, would automatically "know" which page "called" it and be able to provide a Back button (if needed) to navigate back to that page.
Your caveat about users (or browsers, proxies or other components) intentionally turning off the HTTP_REFERER is a valid point and clearly that makes my proposed technique not work, thanks for pointing that out.
I certainly understand your point about it being easy to forget to include the back reference and agree that your method avoids that.
I also didn't mean to say that one should never use HTTP_REFERER--just that it should be done with an awareness of the risks. The truth is that 100% conformance to standards does not necessarily get you an application that everyone can use.
Maybe Oracle could add an APP_PREV_PAGE_ID variable. :-)
Nice trick, very handy.
Thanks for the neat trick.
However, to get it to work we eliminated the INSTR and SUBSTR code. Using the INSTR and SUBSTR code resulted in a corrupted URL.
We changed the PL/SQL code to:
declare l_referer varchar2(500) := owa_util.get_cgi_env('HTTP_REFERER');
return l_referer ;
We are using IE 6.0 and APEX 2.0.
Does anyone have any insight as to why the difference?
My initial post with all that INSTR/SUBSTR showed how to extract just the page# part from the f?p= URL. If you would like to use the entire URL returned by the CGI variable HTTP_REFERER, that is fine too.
Quite useful trick. One thing I noticed was that if the referer url has a port number, the first colon in the referer url will be used to seperate the port number from the server name and the string manipulation will break. Had to modify it to the following to get it to work:
l_referer varchar2(500) := owa_util.get_cgi_env('HTTP_REFERER');
l_referer_query_string := substr(l_referer,instr(l_referer,'?') + 1);
return SUBSTR(l_referer_query_string, INSTR(l_referer_query_string, ':', 1, 1) + 1, INSTR(l_referer_query_string, ':', 1, 1 + 1) - INSTR(l_referer_query_string, ':', 1, 1) - 1);