#(anchor) character in REQUEST_URI
Added by hidden about 14 years ago
I'm long using lighttpd 1.4.28-1 and php-fcgi 5.2.17-1 on my "MyBook World Edition" Networked Hard Drive running "Linux version 2.6.24.4 (brian@dualla) (gcc version 4.2.4)" cpu is ARM926EJ-S rev 5 (v5l), I installed it from optware package and so far it worked great, uses very little memory and runs very fast, but I faced a problem while developing ajax web-site.
I need to access complete request uri in php, but it seems that lighttpd provides to php only a part of it before "#" character. I tried to use rewrite rules, but it seems that lighttpd filter "#" before rewriting. Is there anything I can tweak without recompiling it?
Replies (2)
RE: #(anchor) character in REQUEST_URI - Added by nitrox about 14 years ago
"The # is a special character in a URL, it marks the rest of the URL as a fragment identifier, so everything after it refers to an HTML element id, or a named anchor in the current page."
http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs
RE: #(anchor) character in REQUEST_URI - Added by hidden about 14 years ago
You mean like http://tools.ietf.org/html/rfc3986#page-16
I'm sorry, I guess I wasn't clear enough about my level of understanding of web technology to not get assigned into the newbie group and sent to rtfm.
According to the RFC, "the fragment" is a part of the URI, despite that it is not included in nither $_SERVER['REQUEST_URI'] nor it is in any other $_SERVER variable not even in $HTTP["url"] of configuration file. And the fact that it's optional, states that it doesn't have to be provided by client, but not that it doesn't have to be parsed by server.
And the fact that directing browser to href="#fragment" does not require page to be reloaded makes it very attractive to ajax web-apps, it also being widely used by for example Online Mapping Services as to make sharable links without reloading the whole page which saves more the 80% of traffic/cpu loads.
PS I already anticipated all of the cos and pros for this kind of links. And in my case it's only pros like:
1) All links point to the web-app - accumulating the page rank.
2) Absence of page-reloading - increases efficiency.
3) In script-less browsers I'm still serving the light version of the app for legacy browsers and processing POST requests wile still keeping the same urls - to be shared by users.