Named anchors are not sent to the web server! Who knew?

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!


Evidently browsers, in their little browser brains, universally realize that anchoring to a specific location on the page is a purely client-side behavior that they will take care of themselves.  When making these types of requests, the server only receives a request for the page with any attendant query string parameters:  the browser keeps the named anchor information to itself to use however it sees fit.  It makes no difference what type of web server / server-language you use, I’m here to tell you you aren’t going to get the named anchor in your hand.  The only way to act upon this programmatically is through a JavaScript shim.

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. 

The standard Flash workaround is as follows.  By adding #SomeFakePageName to the url through JavaScript called from Flash, you solve your display and bookmark-setting issues.  Going in the other direction, on page load, if a named anchor exists in the URL, simply push that variable to Flash and have it load up the corresponding ‘page’.  Excellent.  (BTW, I have since been made aware of  swfaddress, a JavaScript library made just for this purpose).

Needless to say (or I wouldn’t bother with this post), my first stab at this was to grab the #SomeFakePageName using server-side C# / ASP.NET and use that to feed my JavaScript whose job it was to tell the Flash which page to go to.  I’m no noob to this kind of thing and have dealt with pretty much every way you can get a handle on a path, rawurl, querstring, you name it from C#, but try as I might I came to realize there is NO WAY to access this one part of the url. .. I will not disclose how much time I spent trying to figure out how to get what was so clearly meant to be gotten, but my lack of wanting to disclose it should speak volumes.

Eventually research and examining HTTP headers lead to my ‘ahh, it’s client-side’ eureka moment. I retooled my C# into JavaScript and and was in business. While this all makes good horse sense, I had never really considered this before and the people I mention this to seem equally shocked to hear about it, and so .. a blog post is born.

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  ( 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 …

Watching the headers of a GET request with a named anchor.


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.



#1 Brian Cook on 05.04.09 at 7:22 am

Interesting. Is this also why Google’s experiments with AJAXified SERPs wasn’t compatible with Google Analytics?

#2 Marius on 05.04.09 at 8:50 am

I think it’s a good thing. We already have ways to send parameters in the URL, and adding a second method would only complicate things.

#3 rkalajian on 05.04.09 at 9:19 am

I often find myself festooning in this line of business. A solid tidbit, that I’m sure will come in handy in the future.

Of course by that time I will have forgotten in, and will most likely end up here when I end up Googling for a solution :)

#4 Nathan on 05.04.09 at 10:36 am

What font are you callouts in? That might be the best looking script font I’ve ever seen…

#5 Duncan on 05.04.09 at 10:43 am

@Nathan.. it’s Jellyka_Estrya_Handwriting.ttf which you can find here:

It sizes kind of strangely but really is nice. Casual but with flair.

#6 I. Knew on 05.04.09 at 10:47 am

I knew.

#7 John Roodel on 05.05.09 at 8:00 am

Oh noes, that spiffy css based tabbed presentation that uses anchors yields no useful web log statistics. If I had know this up front I would have never used this type of design, now I have to redo a series of our most popular pages because we have no data on thier use.

Any thoughts on how to rescue this kind of situation?

#8 Duncan on 05.05.09 at 8:14 am

@John, if you are using Google Analytics you can always capture the clicks to your anchor with Javascript and then hand-call the GA pageTracker() _trackPageview() function, passing in a value meaningful to you for tracking the page …

Leave a Comment