Request.QueryString[] vs. Request.Query.Get() vs. HttpUtility.ParseQueryString()

Question

I searched SO and found similar questions, but none compared all three. That surprised me, so if someone knows of one, please point me to it.

There are a number of different ways to parse the query string of a request... the "correct" way (IMO) should handle null/missing values, but also decode parameter values as appropriate. Which of the following would be the best way to do both?

Method 1

string suffix = Request.QueryString.Get("suffix") ?? "DefaultSuffix";

Method2

string suffix = Request.QueryString["suffix"] ?? "DefaultSuffix";

Method 3

NameValueCollection params = HttpUtility.ParseQueryString(Request.RawUrl);    
string suffix = params.Get("suffix") ?? "DefaultSuffix";

Method 4

NameValueCollection params = HttpUtility.ParseQueryString(Request.RawUrl);    
string suffix = params["suffix"] ?? "DefaultSuffix";

Questions:

1. Would Request.QueryString["suffix"] return a null if no suffix was specified? (Embarrassingly basic question, I know)

2. Does HttpUtility.ParseQueryString() provide any extra functionality over accessing Request.QueryString directly?

3. The MSDN documentation lists this warning:
   
   The ParseQueryString method uses query strings that might contain user input, which is a potential security threat. By default, ASP.NET Web pages validate that user input does not include script or HTML elements. For more information, see Script Exploits Overview.
   
   But it's not clear to me if that means ParseQueryString() should be used to handle that, or is exposed to security flaws because of it... Which is it?

4. ParseQueryString() uses UTF8 encoding by default... do all browsers encode the query string in UTF8 by default?

5. ParseQueryString() will comma-separate values if more than one is specified... does Request.QueryString() do that as well, or what happens if it doesn't?

6. Which of those methods would correctly decode "%2b" to be a "+"?

Showing my Windows development roots again... and I would be a much faster developer if I didn't wonder about these things so much... : P

Bushel

Answer 1

Methods #1 and #2 are the same thing, really. (I think the .Get() method is provided for language compatibility.)

ParseQueryString returns you something that is the functional equivalent of Request.Querystring. You would usually use it when you have a raw URL and no other way to parse the query string parameters from it. Request.Querystring does that for you, so in this case, it's not needed.

1. You can't leave off "suffix". You either have to pass a string or an index number. If you leave off the [] entirely, you get the whole NameValueCollection. If you mean what if "suffix" was not one of the QueryString values then yes; you would get null if you called Request.QueryString["suffix"].

2. No. The most likely time you would use it is if you had an external URL and wanted to parse the query string parameters from it.

3. ParseQueryString does not handle it... neither does pulling the values straight from Request.QueryString. For ASP.NET, you usually handle form values as the values of controls, and that is where ASP.NET usually 'handles' these things for you. In other words: DON'T TRUST USER INPUT Ever. No matter what framework is doing what ever for you.

4. I have no clue (I think no). However, I think what you are reading is telling you that ParseQueryString is returning UTF-8 encoded text - regardless if it was so encoded when it came in.

5. Again: ParseQueryString returns basically the same thing you get from Request.QueryString. In fact, I think ParseQueryString is used internally to provide Request.QueryString.

6. They would produce the equivalent; they will all properly decode the values submitted. If you have URL: http://site.com/page.aspx?id=%20Hello then call Request.QueryString["id"] the return value will be " Hello", because it automatically decodes.

Vexatious

Sorry, the 'suffix' omission was for brevity only... should've been clearer. Sorry for not getting back to the answers sooner, it's been a really crazy week. Let me look closer at these tomorrow. Thanks! – Bushel

Ah, wait, better understand your answer to #1... I meant if "suffix" was omitted from the request string – Bushel

Hey, Andrew, thanks for the answer... sorry, this got lost in the shuffle, never got to answer it. My semi-annual old-answer review uncovered it : ) – Bushel

Answer 2

Example 1:

string itsMeString = string.IsNullOrEmpty(Request.QueryString["itsMe"]) ? string.Empty :  HttpUtillity.UrlDecode(Request.QueryString["itsMe"]);

Stright to your questions:

1. Not quite sure what do you mean by suffix, if you are asking what happens if the key is not present(you don't have it in the QueryString) - yes it will return null.
2. My GUESS here is that when constructed, Request.QueryString internally calls HttpUtillity.ParseQueryString() method and caches the NameValueCollection for subsequential access. I think the first is only left so you can use it over a string that is not present in the Request, for example if you are scrapping a web page and need to get some arguments from a string you've found in the code of that page. This way you won't need to construct an Uri object but will be able to get just the query string as a NameValueCollection if you are sure you only need this. This is a wild guess ;).)
3. This is implemented on a page level so if you are accessing the QueryString let's say in Page_Load event handler, you are having a valid and safe string (ASP.NET will throw an exception otherwise and will not let the code flow enter the Page_Load so you are protected from storing XSS in your database, the exception will be: "A potentially dangerous Request.QueryString value was detected from the client, same as if a post variable contains any traces of XSS but instead Request.Form the exception says Request.QueryString."). This is so if you let the "validateRequest" switched on (by default it is). The ASP.NET pipeline will throw an exception earlier, so you don't have the chance to save any XSS things to your store (Database). Switching it off implies you know what you're doing so you will then need to implement the security yourself (by checking what's comming in).
4. Probably it will be safe to say yes. Anyway, since you will in most cases generating the QueryString on your own (via JavaScript or server side code - be sure to use HttpUtillity.UrlEncode for backend code and escape for JavaScript). This way the browser will be forced to turn "It's me!" to "It%27s%20me%21". You can refer to this article for more on Url Encoding in JavaScript: http://www.javascripter.net/faq/escape.htm.
5. Please elaborate on that, couldn't quite get what do you mean by "will comma-separate values if more than one is specified.".
6. As far as I remember, none of them will. You will probably need to call HttpUtillity.UrlDecode / HttpUtillity.HtmlDecode (based on what input do you have) to get the string correctly, in the above example with "It's me!" you will do something like (see Example 1 as something's wrong with the code formatting if I put it after the numbered list).

Yachtsman

Your number 6 is not correct, and your example code could cause over-decoding. If you have URL: http://site.com/page.aspx?id=%20Hello then call Request.QueryString["id"] the return value will be " Hello", because it automatically decodes. – Vexatious

Hi, sorry for the delay in responding... I will look at this more tomorrow. Thanks! – Bushel

Thanks for the info! Sorry to take so long to reply; I gave Andrew credit for some of his specifics, but I upvoted yours. Thanks again! – Bushel