Here’s a quickie for you. One of those typical gotchas you never see coming until you need to do something seemingly obvious, only to spend a bunch of time banging your head against the wall in frustration, festooning the atomosphere above your desk with rebarbative expletives, and shaking your fist impotently at the heavens. AKA a typical Tuesday.
The quick bottom line ….
When a browser requests a url with a named anchor at the end, the named anchor is NOT part of the request!
BTW, according to the W3C a named anchor is a properly referred to as a "fragment identifier", but I’ll dispense with calling it that as I’ve never heard any real person ever refer to one as such.
Where this bit me in the ass:
In general practice you probably don’t need to care much about this behavior, I certainly didn’t and only marginally do now and I’m writing this friggin’ post. Chances are all you want to do is anchor down somewhere in the page, and if this is the case, your request will be fulfilled as you’d imagine it would be. Where you run into problems is when you think you are being clever (as I often find myself) and co-opting the anchor for some ulterior purpose. In my case, I was working with our Flash guy on an almost entirely Flash driven site. As with any Flash site, when you click the navigation, you can get to any numbers of new screens of information, but html-request-wise, all the client has really ever done is load the initial default page.
This situation was has two drawbacks.
1) Visitors can’t bookmark a specific ‘page’ on your site as the URL never changes.
2) You can’t send any linked traffic to a specific page of the site. You might want to promote the information found on ‘page 3’ of your Flash site, but don’t have a way to link there aside from funneling people who have already expressed a very specific interest in ‘page 3′ to your main page and forcing them to navigate their way in from there.
Go ahead, check it out for yourself!
I encourage you to view this for yourself. Using the Live HTTP Headers Firefox extension or a broswer-agnostic tool like Fiddler , go to a url with a named anchor like this W3C page on fragment identifiers (http://www.w3.org/TR/html401/intro/intro.html#fragment-uri) and watch the request. You will see that the GET sent to the server does NOT include the #fragment-uri you’ll see in your browsers location bar …
Final thoughts of thinly-veiled bitterness:
While all of this makes sense in that the named anchor part triggers client-side-only behavior, I think most people probably assume that it’s part of the request anyway. I’d never really thought about my browser slicing and dicing the URL from the location and taking it upon itself to override my simple puny human’s direct instructions and to instead only send the actionable bits as part of the GET, as wonderfully efficient as that might be. So good for you, you smarmy browsers, you’re soooo friggin’ smart.