SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    SitePoint Wizard
    Join Date
    Oct 2005
    Location
    London
    Posts
    1,678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    parent.document.referrer loses anchor in url

    Hi,

    I have a system working on my siute that allows users to follow links. When they click on a link the new page opens
    in a frame. Above the frame is another frame with my sites branding and a return button.

    I;m using parent.document.referrer to set the return buttons url so it returns the user
    back to where they were on my site. Problem is my site involves using tabs on a page so sometimes
    the url contains a #...like so..... http://www.mysite/html/page.html#anchor 2. The #anchor 2 bit is getting lost so
    although i get taken back to the right page i don't get taken back to the correct area.

    Any ideas?

    Heres the code:

    if (parent.document.referrer!=null)
    alert(parent.document.referrer);
    $("returnButton").href = parent.document.referrer;


    Thanks

  2. #2
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The fragment identifier is just an instruction to the user agent, it's ignored by the server. It can't be part of a referrer URI, since it's very hard to know if the user was 'at' that fragment identifier when activating the link. Even if the browser's address field contains the fragment identifier, the user may have scrolled the page, and so on.

    Besides, you really shouldn't depend on referrer information. Good browsers allow it to be disabled, and proxies and firewalls can strip it out.

    If you need a 'return URI' you should pass it as a parameter to the script you're linking to.
    Birnam wood is come to Dunsinane

  3. #3
    SitePoint Wizard
    Join Date
    Oct 2005
    Location
    London
    Posts
    1,678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you need a 'return URI' you should pass it as a parameter to the script you're linking to.
    Hi,

    How would i pass it as a parameter? Do you mean pass it as a query string ($_GET) ?

    Why would a firewall strip out the HTTP_REFERER?
    Last edited by elduderino; Jun 30, 2008 at 15:22.

  4. #4
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by elduderino View Post
    How would i pass it as a parameter? Do you mean pass it as a query string ($_GET) ?
    Yes, as a query parameter:
    Code HTML4Strict:
    <a href="second.php?back=first.php%23anchor">link</a>
    (%23 is an URL-encoded '#' character.)

    Quote Originally Posted by elduderino View Post
    Why would a firewall strip out the HTTP_REFERER?
    Paranoia.
    In the log files from my blog, I sometimes see the referrer listed as 'field stripped by firewall'. Some organisations don't want links to their sites, at least not if they can't have any control over them.
    Many security-conscious users also disable referrer information in their browsers (it's just two keypresses in Opera, for instance).
    Birnam wood is come to Dunsinane

  5. #5
    SitePoint Wizard
    Join Date
    Oct 2005
    Location
    London
    Posts
    1,678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    right great thanks

    I'm now passing the return uri as a query string. I can pick it up in the next page and alert it out:

    var hr = parent.document.location;
    alert(hr);


    //gives http://10.10.10.99/oursite/html/fram...html%23anchor3

    But if I try (where 'ruri=' is the url parameter):

    if (hr.indexOf('ruri=') > -1 ) {
    alert('hello');


    i do not get the alert(hello) back....although i definately should as i can see it's there in the url

    Any ideas...? I'm sure it's something really stoopid i'm missing!
    Last edited by elduderino; Jul 1, 2008 at 03:43.

  6. #6
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    document.location is an object with a number of properties and methods. Try this instead,
    Code JavaScript:
    var hr = parent.document.location.href;
    alert(hr);
     
    if (hr.indexOf('ruri=') > -1 ) {
        alert('hello');
    }
    Birnam wood is come to Dunsinane

  7. #7
    SitePoint Wizard
    Join Date
    Oct 2005
    Location
    London
    Posts
    1,678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice one. I really appreciate your time. Thanks for your help with this.

  8. #8
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You're welcome! I'm happy to help.
    Birnam wood is come to Dunsinane

  9. #9
    SitePoint Wizard
    Join Date
    Oct 2005
    Location
    London
    Posts
    1,678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The fragment identifier is just an instruction to the user agent, it's ignored by the server. It can't be part of a referrer URI, since it's very hard to know if the user was 'at' that fragment identifier when activating the link. Even if the browser's address field contains the fragment identifier, the user may have scrolled the page, and so on.
    Any chance you could link me to the resource where this info came from? I need to clarify the matter with my superiors and they're not accpeting my/your argument...although it makes perfect sense!!! I've googled it in every way i can think but not getting the answer....


    It's working but it's very fickle....i'm correctly assigning the url (with the anchor bit) to my button. When you hover over the button you can clearly see that the url is correct but when you click it sometimes it seems to get lost and i end up back at my original page but not at the correct anchor...it gets completely lost.

    Funnily enough it seems to act the same as the browser back button...sometimes that remembers my anchor info and others it doesn't....flaky behaviour! It's worse in IE than FF.

    Heres the relevant code:
    Code JavaScript:
    function setButton(){
        var hr = parent.document.location.href;
        var u = '&ruri=';
        if(hr.indexOf(u) > -1 ) {
            var linkBack = hr.substr(hr.indexOf(u));
    	    linkBack = linkBack.substr(6);
    		linkBack = decodeURIComponent(linkBack);
     
    		$("returnButton").href = linkBack;
    	}
     
    }

    So as i say returnButton definately get assigned with the correct link back but it's getting lost
    Last edited by elduderino; Jul 2, 2008 at 08:18.

  10. #10
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by elduderino View Post
    Any chance you could link me to the resource where this info came from? I need to clarify the matter with my superiors and they're not accpeting my/your argument...although it makes perfect sense!!! I've googled it in every way i can think but not getting the answer....
    I bet you're going to be sorry you asked me this.
    It's defined in RFC 1808. Happy reading!

    Here's a relevant excerpt from section 2.4.1:
    If the parse string contains a crosshatch "#" character, then the substring after the first (left-most) crosshatch "#" and up to the end of the parse string is the <fragment> identifier. If the crosshatch is the last character, or no crosshatch is present, then the fragment identifier is empty. The matched substring, including the crosshatch character, is removed from the parse string before continuing.

    Note that the fragment identifier is not considered part of the URL. However, since it is often attached to the URL, parsers must be able to recognize and set aside fragment identifiers as part of the process.
    (My emphasis.)
    Birnam wood is come to Dunsinane

  11. #11
    SitePoint Wizard
    Join Date
    Oct 2005
    Location
    London
    Posts
    1,678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice! Tommy have you read all the rfc documents? If you you're a braver man than I am. I'm going to have a read of that one tommorrow

    So the fragment identifier is not considered part of the url...so could this explain why it sometimes gets lost in my javascript back button and the browser back button?

  12. #12
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by elduderino View Post
    Nice! Tommy have you read all the rfc documents?
    Of course! Haven't everyone?
    Just kidding. I haven't even read all of that one, although I bet it's great bedtime reading …

    Quote Originally Posted by elduderino View Post
    So the fragment identifier is not considered part of the url...so could this explain why it sometimes gets lost in my javascript back button and the browser back button?
    Probably not. I'd put those down to 'browser quirks'.
    Birnam wood is come to Dunsinane

  13. #13
    SitePoint Wizard
    Join Date
    Oct 2005
    Location
    London
    Posts
    1,678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes it's a pretty heavy going document....as i imagine is true for all the ref docs!

    Just one more question....i really need the 'back button' to always retain the anchor....it's kind of critical for the usability of this particular site.

    Do you think if i had a script that ran everytime i clicked an external link ( therefor taking me to the page with my frameset at the top), which looked at the url, if it has a resource identifier then convert the info in that identifier in to a query string to be read by the script on the framset page.

    Then if the frameset script finds the query string it sends one back when the user clicks the back to my site button. Then in the original page make another script look for that query string and if it's there then write the url out with the fragment identifier.

    So essentially bypassing the fragment identifier and replacing it with a query string. Could it work??

  14. #14
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You might be able to make it work, but I have to ask: why bother going through so much trouble to replicate a feature that's been built into every browser from day one?

    Usually, the first thing a total beginner learns is that blue, underlined text can be clicked to take you somewhere interesting. The second thing they learn is to use the Back button when they find out that the link that says 'cheap dog food' actually leads to a hardcore adult site.

    What I mean is that virtually every user will know how to make use of the Back button in their browser. Are you sure you need to replicate it?
    Birnam wood is come to Dunsinane

  15. #15
    SitePoint Wizard
    Join Date
    Oct 2005
    Location
    London
    Posts
    1,678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well i agree, i don't see the point either, but it's a feature that's been implemented by some previous developers. I've now been lumbered with the task of making it work like a back button to the letter. Unfortunately my superiors aren't web developers so it's a 'well why can't it work like that' attitude from them.

  16. #16
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ah.
    I recognise that attitude, and can do no more than wish you the best of luck with your endeavour.
    Birnam wood is come to Dunsinane


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •