468,771 Members | 1,925 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,771 developers. It's quick & easy.

Request.QueryString and Server.URLDecode()

Does Server.URLDecode() need to be applied to Request.QueryString(<key
name>) ?
Nov 19 '05 #1
6 11634
"John Grandy" <johnagrandy-at-yahoo-dot-com> wrote in news:OVxu7q5nFHA.4056
@TK2MSFTNGP10.phx.gbl:
Does Server.URLDecode() need to be applied to Request.QueryString(<key
name>) ?


Yes - if the string is encoded. Request.Querystring returns the raw
(undecoded) text.

--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Nov 19 '05 #2
Yes, as I discovered this is also important when using Base64-encoded
strings in the QueryString. Here's what I use to combat frustration:

string sOKForBase64Decrypt =
Server.UrlDecode(Request.QueryString["argument"].ToString()).Replace("
","+")

-- Sean M

"John Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message
news:OV**************@TK2MSFTNGP10.phx.gbl...
Does Server.URLDecode() need to be applied to Request.QueryString(<key
name>) ?

Nov 19 '05 #3
Hmmm ...

My tests don't show any need to apply Server.URLDecode() to
Request.QueryString()

I tested a return URL of

http://localhost/Results.aspx?search...re+some+spaces

Debug-mode stepping through the server-side code ,
Request.QueryString("search") contains the value "here are some spaces" (no
plus signs are included)



"Sean M" <ta******@hotmail.com> wrote in message
news:O4**************@TK2MSFTNGP09.phx.gbl...
Yes, as I discovered this is also important when using Base64-encoded
strings in the QueryString. Here's what I use to combat frustration:

string sOKForBase64Decrypt =
Server.UrlDecode(Request.QueryString["argument"].ToString()).Replace("
","+")

-- Sean M

"John Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message
news:OV**************@TK2MSFTNGP10.phx.gbl...
Does Server.URLDecode() need to be applied to Request.QueryString(<key
name>) ?


Nov 19 '05 #4
Lucas Tam wrote:
"John Grandy" <johnagrandy-at-yahoo-dot-com> wrote in
news:OVxu7q5nFHA.4056 @TK2MSFTNGP10.phx.gbl:
Does Server.URLDecode() need to be applied to
Request.QueryString(<key name>) ?


Yes - if the string is encoded. Request.Querystring returns the raw
(undecoded) text.


Um... no. Items retrieved from the QueryString collection have already
been decoded (anything else would be disastrous).

Cheers,
--
http://www.joergjooss.de
mailto:ne********@joergjooss.de
Nov 19 '05 #5
"Joerg Jooss" <ne********@joergjooss.de> wrote in news:xn0e643z6a3rc8n004
@msnews.microsoft.com:
Yes - if the string is encoded. Request.Querystring returns the raw
(undecoded) text.


Um... no. Items retrieved from the QueryString collection have already
been decoded (anything else would be disastrous).


Oops you're right : )

Always thought you needed to run it through Server.URLDecode.

--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Nov 19 '05 #6
"John Grandy" <johnagrandy-at-yahoo-dot-com> wrote in news:ueSagefoFHA.3256
@tk2msftngp13.phx.gbl:
Hmmm ...

My tests don't show any need to apply Server.URLDecode() to
Request.QueryString()


I think it may of been out of habit from ASP days???

--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Nov 19 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Ammar | last post: by
3 posts views Thread by Axel Dahmen | last post: by
1 post views Thread by EoRaptor013 | last post: by
2 posts views Thread by ffrugone | last post: by
3 posts views Thread by Tom | last post: by
3 posts views Thread by Bob | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
1 post views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.