Published: Thursday, April 26, 2001
Using Server.URLEncode
By Jeffrey Humpherys
After failing to find a 4Guys article that explains the usefulness of
Server.UrlEncode I decided to write one. I only learned about this nifty
method a few weeks ago and I thought I would share it with y'all.
Basically, the Server.UrlEncode method takes a string input and converts
non-alphanumeric symbols into their ASCII Hex equivalents with a
% in front (spaces are converted into + symbols). For example, if
we have the string strURL assigned like so:
strURL = "http://www.4guysfromrolla.com/default.asp?id=123&usr=bob"
|
calling Server.URLencode(strURL) would return:
http%3A%2F%2Fwww%2E4guysfromrolla%2Ecom%2Fdefault%2Easp%3Fid%3D123%26usr%3Dbob
|
[
View the live demo!]
You may be wondering, for good reason, why (and how on Earth) the Server.UrlEncode method
is useful. Imagine, though, that you wanted to pass such a string as strURL through the querystring.
For example, assume that you had an HREF tag like so:
<a href="http://www.myserver.com/SomePage.asp?URL=http://www.4guysfromrolla.com/default.asp?id=123&usr=bob">
Click me!
</a>
|
Now, when the user clicked on the hyperlink generated by the HREF tag, what should happen is the ASP page http://www.myserver.com/SomePage.asp would be called
with the querystring ?URL=http://www.4guysfromrolla.com/default.asp?id=123&usr=bob. However, ask yourself
this: how is the Web server (IIS) supposed to know where the querystring begins (and, therefore, where the requested URL
ends)? You might say, "Easy, at the
?." Well... which one? There's two! One after SomePage.asp and one after
default.asp. Also, what are the name/value pairs in the querystring? Remember that each name/value
pair is separated by an ampersand. We mean to have only one name/value pair: the name being URL and the
value being http://www.4guysfromrolla.com/default.asp?id=123&usr=bob. But with an unencoded querystring,
it is ambiguous, since usr=bob could be interpretted as its own name/value pair, thereby giving us
two name/value pairs (URL=http://www.4guysfromrolla.com/default.asp?id=123 and usr=bob). To resolve these problems (and the problem of having other non-alphanumeric characters in
the URL/querystring), use Server.UrlEncode, which will successfully map those "illegal" non-alphanumeric
characters into the correct ASCII codes.
Let's take a moment to look at a real-world example.
A previous 4Guys article, Simple Authentication
illustrates how to create "secure" ASP pages, ones accessible only by those who have "logged in."
This is accomplished by adding a few lines of code at the top of each protected .asp page, which
checks a Session variable to determine if a user is logged in. If the user has been logged in, they are allowed
to view the page; if, however, the user has not been logged in, they are redirected to a login page.
However, it's important when sending someone to the login page that you "remember" the page they were trying to
access so that you redirect the user back to the original request once they have successfully logged in.
Hence you need to pass the URL of the page they originally tried to request to the login page so that the
login page knows how to get the user back to their originally-requested page!
The two basic methods for doing this are either placing the URL in a
hidden variable or in the querystring. The Simple Authentication
article uses both: on each page that checks the Session variable to determine if the user is not logged in, the
user is sent to the Login page (Authenticate.asp) and the current URL is passed through the querystring
using Server.UrlEncode; once in Authenticate.asp, the user is prompted for her username/password -
it is at this juncture that the URL is stuffed into a hidden form variable and passed along to the validation page
(Validate.asp) once the user submits the login form.
Personally, I generally prefer sticking with the querystring approach for all instances. One main reason is
because you can run into problems with client proxy servers caching pages, but other
advantages may include not having those annoying refresh warnings when you
hit the back button, the ability to bookmark/email the link, etc.
Ok, now that you know how to encode, you may be wondering how in the world to decode. Fortunately,
it's quite simple - in fact, you don't have to do anything different! Just use Request.Querystring
like you normally do to read values from the querystring - the decoding (the coversion from the ASCII equivalent of
non-alphanumeric characters back to their original character form) will occur automagically. If you think
about what Request.Querystring does, it will make sense.
Let's look at a complete example that both encodes a querystring and then reads it in from another page.
Let's take our string from before:
strURL = "http://www.4guysfromrolla.com/default.asp?id=123&usr=bob"
'Now, encode the string
strEncodedURL = Server.URLencode(strURL)
|
At this point strEncodedURL has the value:
http%3A%2F%2Fwww%2E4guysfromrolla%2Ecom%2Fdefault%2Easp%3Fid%3D123%26usr%3Dbob
|
If we attach it to the URL of our login page while performing a redirect:
Response.redirect "login.asp?backlink=" & strEncodedURL
|
Then our login URL becomes:
login.asp?backlink=http%3A%2F%2Fwww%2E4guysfromrolla%2Ecom%2Fdefault%2Easp%3Fid%3D123%26usr%3Dbob
|
Now, to read the original link back from login.asp all we need to do is call Request.QueryString
like we normally would:
Request.Querystring("backlink")
|
which returns the original value, i.e.,
http://www.4guysfromrolla.com/default.asp?id=123&usr=bob
|
Pretty cool, huh? If you want, you can view the technical docs
for Server.UrlEncode, but they are pretty shabby. (Be sure to view the live demo.)
Happy Programming!
By Jeffrey Humpherys
