Parse URL with a hashmark (#)

How can I get the data AFTER a hashmark from the current URL

[knnknn]

I want to know the EXACT URL as written in the browser window.

Unfortunately $HTTP_SERVER_VARS["QUERY_STRING"] doesn't work with hashes "#"

Thus an url such as
http://www.abc.com/def.htm#ghi
parses as
http://www.abc.com/def.htm
and the anchor pointer "ghi" gets lost.

I want to read "ghi" into a php variable and save it into a cookie. How can this be done?

Thank you very much for any input.

[edited by: jatar_k at 12:11 am (utc) on Jan. 28, 2004]
[edit reason] delinked [/edit]

[justageek]

You could do:

$anchor_pointer = split('#','http://www.abc.com/def.htm#ghi',1);

Then $anchor_pointer[1] would have the info in it.

JAG

[Timotheos]

Does $HTTP_SERVER_VARS['REQUEST_URI'] work?

[knnknn]

Nope it parses as "/def.htm"

@justageek:
The "splitting" itself is not the problem. To KNOW what is in the browser URL field is the problem.

[justageek]

Not sure what you mean? I thought you just wanted to assign that value into a cookie....yes?

JAG

[knnknn]

I meant what I wrote:

1) I want to KNOW what's after the hashmark (<- that's the problem)
2) Write it into a cookie via php (<- that's not the problem, but it tells you that I cannot use javascript to read out the URL)

[coopster]

I believe what knnknn is stating is that the URL is not returning what is expected, at least not from the QUERY_STRING environment variable. The anchor name is not returned in the QUERY_STRING. Timotheos may have been on the right track by pointing toward a different variable. Try HTTP_REFERER, although that's not always present...

[justageek]

I want to KNOW what's after the hashmark

Let's try it another way...when do you want to KNOW that and what is it that you are trying to do? I see what coopster is saying now I understand. Try parse_url().

JAG

[coopster]

JAG, take it for face value...I might not be correct here! I think what knnknn is trying to do is get the URL from the page the person is POSTing a <form> from. I'm not sure I'm on track yet. Waiting to here from knnknn.

Keep on it, JAG!

[justageek]

Keep on it, JAG!

I hate for someone not to get the answers when I know we can answer it......if we understand the question ;-)

If you are right then the parse_url on the referer would work....assuming the referer was sent of course.

JAG

[knnknn]

OK, let's say abc.com links to mysite.com as
mysite.com/index.php#abc

xyz.com links to me as
mysite.com/index.php#xyz

How can I DISPLAY on index.php "ABC" or "XYZ"?

When I use
<?php echo $HTTP_SERVER_VARS["REQUEST_URI"]?>
it returns
"/index.php"
INSTEAD of the wanted
"/index.php#abc"

[coopster]

Ahh! (lights go on). Try checking one of the other $_SERVER variables. Possibly

$_SERVER['PHP_SELF'] 
$_SERVER['argv'] 

...or better yet, run this at the top of the php script being linked to you to see what, if anything you can use, is available:

print '<pre>'; 
print_r($_SERVER); 
print '</pre>'; 

Oh, I see you are using $HTTP_SERVER_VARS. Then use this:

print '<pre>'; 
print_r($HTTP_SERVER_VARS); 
print '</pre>'; 

[knnknn]

Nope, nothing works.
It always drops everything after "#"

I also tried Netscape and Opera without success.

[coopster]

You are right, none of the $_SERVER variables return the anchor name. As a matter of fact, I printed out all of the PHP Predefined Variables [php.net] and found nothing.

I just tested this as you are describing it and I understand what you are getting at now. I created a simple page with an

<a href="http:://mysite.com/test.php#shopping">Shopping</a>

link and at the top of my

test.php

script I dumped all the variables to see what was available. Plenty! But no anchor name!

Leads me to wonder if this isn't an HTTP server configuration or directive that needs to be set. Anyone?

[BitBanger]

I think the anchors are stripped at the client side. The browser requests the page, then after receiving it, looks for the named anchor. This is why linking to a named anchor in the current page doesn't reload the page.

In other words, I don't believe the request is possible.

[coopster]

I thought that at first, too. I found this on the WebmasterWorld Forums

Getting anchor from URL [webmasterworld.com]

There is a statement in there by a respected member of the WebmasterWorld community that the anchor name never leaves the browser.

What perplexes me is how does it show up in the address bar of my browser once the test.php script is executed and returns the HTML? I mean, really, if the anchor name never left the browser, where does the browser get the value to be displayed? It must be retained and managed by the user agent. I wonder where we could find supporting documentation for this theory?

[knnknn]

Both Javascript methods work
document.write(document.URL);
document.write(location.href);

OK, I won't state here that "Javascript rulez" but it's interesting that Javascript in this case is stronger than PHP.

[sabai]

Anything after the hash is only ever used on the client side - never passed to the server. Javascript is client side...

[coopster]

Supporting documentation?

[knnknn]

Hey, I found out there there is even the Javascript function
location.hash
that delivers everything from (+including) the hash.

abc.com/index.htm#xyz
->
document.write(location.hash)
-> #xyz

[coopster]

I thought you said you cannot use javascript (msg #6)?

[knnknn]

Yes, I couldn't.

It seems I have to redesign some things and combine Javascript+PHP which basically sucks, but what can I do?

[coopster]

If it is critical that you get the anchor name, JavaScript or some other client-side scripting solution seems your only option. Do what you have to :)

Also, I found some supporting documentation. Although this property does not appear in the
W3 DOM specification [w3.org] for the A [w3.org] element, it is my understanding it is present in modern browsers for backward-compatibility. The hash property navigates to the named anchor without reloading the document.

RFC 1738 [rfc-editor.org] is the reference for complete information about the hash. It has been updated by:
RFC1808 [rfc-editor.org], RFC2368 [rfc-editor.org], RFC2396 [rfc-editor.org]

[Timotheos]

Found this on a Google group...

The authoritative source for such information is the relevant RFC 2396.
Specifically, you should read section 4.1, which reads:

When a URI reference is used to perform a retrieval action on
the identified resource, the optional fragment identifier,
separated from the URI by a crosshatch ("#") character, consists
of additional reference information to be interpreted by the user
agent after the retrieval action has been successfully completed.
As such, it is not part of a URI, but is often used in
conjunction with a URI.

Thus, we can conclude that browsers do not send the fragment
identifier to the server. Instead they keep it, and apply it after
the resource has been sent to them. Of course, to be of any use
whatsoever, the identified fragment must be defined within that
resource.

[coopster]

Right on, Timotheos, thanks for the update. I found my lead by going back to the JavaScript 1.3 Reference Guide, of all places. I couldn't find it in neither the JS 1.4 nor 1.5 guides. But in the JS 1.3 it referred to the RFC mentioned. I love closure :)

[dubmeier]

Empirical evidence! I looked into this problem using @stake's webproxy tool. It intercepts all http requests from your browser and logs them.

Result: the theory is correct. The # hash mark is not sent in an HTTP GET request (at least not from IE 6.x).