# sign

Topics: Developer Forum, Project Management Forum, User Forum
Jul 14, 2009 at 10:26 PM

Hello. I need to include a "#" sign inside a hash'ed variable. Like 


accesskey=aaabbb#cFDGFDSGDFGFD (whatever)


But the rewriter (wonderful by the way, thank you) isn't processing it. Do you know if there is a solution? 


Thank you.



Jul 14, 2009 at 10:47 PM

You're welcome.

The # char is special.  It is interpreted by browsers as a flag for a local "named" anchor. - in other words an anchor (<a>) in the document that is already loaded.  If you connect your browser to a debugging proxy, like Fiddler, you will see that when the browser GETs a link that includes a query string which itself includes a #, the URL is truncated just before the #.  In other words, suppose there is a link like 


...in a document. If you click on that link you will see that the actual URL sent to the server is


If you really need to do a GET on a URL that includes #, then you must URL-encode the character. Replace it with %23. You will have to decode it on the other end.

Maybe what you mean is you are trying to embed the # into a querystring within the filter rewrite rules (or redirect rules). There again, you will have to url-encode the # in order to embed it.

Jul 14, 2009 at 11:02 PM

Thanks for your reply. What I was trying to write is this...

I would like the rewriter to allow a user to click on a page that Already has the "#" inside the URL. Then, I don't care if I have to rewrite it to ASCII (%23), or whatever....but I would like to be able to still redirect the page just like normal.

Normal Example: http://www.mycompany.com/index.html ----------------goes to------> http://www.mycompany.com/mysite/index12.html

But this example would be this in theory:

http://www.mycompany.com/index.html?accessid=abc#someotherstuffblabla ----------------goes to------> http://www.mycopmany.com/portalauth/index.html?accessid=abc#someotherstuffblabla


...Meaning....I just want to be able to "forward on" the URL in full like I normally do. It's just that the rewriter barfs (I'm sure by design) when it sees the #. Is there a fix for this? Maybe another filter before the rewriter?


Thanks for your help

Jul 14, 2009 at 11:41 PM
Edited Jul 14, 2009 at 11:44 PM

Hmmm, I didn't explain well.  The naked # character is NEVER sent by the browser to the server.   I am pretty sure that it is not IIRF that is stripping the character or barfing on it.   Do you have a log file from IIRF showing that it actually received the # ??  I would be very surprised, and I'd like to see it. 

The reason is that # within a URL is treated as a delimiter between the URL and a fragment identifier. (see Wikipedia) by compliant HTTP applications, like web browsers.  I wrote this before and I don't know how to say it more clearly, so I will write it again: 

suppose there is a link like
...in a document. If you click on that link, the actual URL sent to the server is

Some implications:

  • The # character is not sent from the browser to the server.
  • IIRF is not barfing on the # character.
  • IIRF never gets the # character.
  • There is no "fix" for IIRF available that changes this.
  • This is not a n example of a problem in IIRF.  The behavior you described is expected, correct behavior.
  • The browser uses the # character as a reference to a location in the document it retrieved, where the URL for the doc retrieved is everything before the # character.
  • If you want a # character in your accessKey, you should encode it as %23.

If this isn't clear, I suggest you read IETF RFC 2396. Here's a relevant excerpt from Section 4.1:

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.
Jul 14, 2009 at 11:47 PM

Here's another thread on the same topic.

Thread 1460