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

Я искал SO и нашел похожие вопросы, но ни один из них не сравнивал всех трех. Это меня удивило, поэтому, если кто-то знает об одном, пожалуйста, укажите мне его.

Существует несколько различных способов анализа строки запроса запроса. "Правильный" способ (IMO) должен обрабатывать нулевые/отсутствующие значения, а также, при необходимости, декодировать значения параметров. Какое из следующего было бы лучшим способом сделать оба?

Метод 1

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

Method2

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

Метод 3

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

Метод 4

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

Вопросы:

Будет ли Request.QueryString["suffix"] возвращать значение null, если суффикс не указан? (Смущающе основной вопрос, я знаю)
Предоставляет ли HttpUtility.ParseQueryString() дополнительную функциональность для прямого доступа к Request.QueryString?
В документации MSDN указано это предупреждение:

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.

Но мне непонятно, если это означает, что ParseQueryString() следует использовать для обработки этого или из-за него обнаруживаются недостатки безопасности... Что это?
ParseQueryString() по умолчанию использует кодировку UTF8... все браузеры по умолчанию кодируют строку запроса в UTF8?
ParseQueryString() будет разделять запятые значения, если указано больше одного... делает это Request.QueryString(), или что произойдет, если это не так?
Какой из этих методов будет правильно декодировать "%2B" как "+"?

Показывая мои корни разработки Windows еще раз... и я был бы гораздо более быстрым разработчиком, если бы я не задумывался об этих вещах так много...: P

Ответ 1

Методы # 1 и # 2 - это одно и то же. (Я думаю, что метод .Get() предоставляется для языковой совместимости.)

ParseQueryString возвращает вам что-то, что является функциональным эквивалентом Request.Querystring. Обычно вы используете его, когда у вас есть необработанный URL-адрес и нет другого способа анализа параметров строки запроса из него. Request.Querystring делает это для вас, поэтому в этом случае он не нужен.

Вы не можете оставить "suffix". Вам либо нужно передать строку, либо номер индекса. Если вы полностью опустите [], вы получите целое NameValueCollection. Если вы имеете в виду, что если "suffix" не был одним из значений QueryString, тогда да; вы получите null, если вы вызвали Request.QueryString["suffix"].
Нет. Скорее всего, вы будете использовать его, если у вас есть внешний URL-адрес и вы хотите выполнить синтаксический анализ параметров строки запроса.
ParseQueryString не справляется с этим... и не вытягивает значения прямо из Request.Querystring. Для ASP.NET вы обычно обрабатываете значения форм как значения элементов управления, и именно там ASP.NET обычно "обрабатывает" эти вещи для вас. Другими словами: НЕ ДОПУСКАЙТЕ ПОЛЬЗОВАТЕЛЬ. Независимо от того, какие рамки делают то, что когда-либо для вас.
У меня нет подсказки (я думаю, нет). Однако я думаю, что то, что вы читаете, говорит вам, что ParseQueryString возвращает кодированный текст UTF-8 - независимо от того, был ли он так закодирован, когда он вошел.
Снова: ParseQueryString возвращает в основном то же самое, что вы получаете от Request.Querystring. На самом деле, я думаю, ParseQueryString используется внутри, чтобы обеспечить Request.Querystring.
Они будут производить эквивалент; все они должным образом декодируют представленные значения. Если у вас есть URL: http://site.com/page.aspx?id=%20Hello, тогда вызывается Request.QueryString["id"], возвращаемое значение будет " Hello", потому что оно автоматически декодирует.

Ответ 2

Пример 1:

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

Устремляйтесь к своим вопросам:

Не совсем уверен, что вы подразумеваете под суффиксом, если вы спрашиваете, что произойдет, если ключ отсутствует (у вас его нет в QueryString) - да, он вернет null.
Мой GUESS здесь заключается в том, что при построении Request.QueryString внутренне вызывает метод HttpUtillity.ParseQueryString() и кэширует NameValueCollection для последующего доступа. Я думаю, что первый из них оставлен, поэтому вы можете использовать его над строкой, отсутствующей в запросе, например, если вы отказываетесь от веб-страницы и вам нужно получить некоторые аргументы из строки, которую вы нашли в коде этого стр. Таким образом вам не нужно будет создавать объект Uri, но он сможет получить только строку запроса как NameValueCollection, если вы уверены, что вам это нужно. Это дикая догадка;).)
Это реализовано на уровне страницы, поэтому, если вы обращаетесь к QueryString, скажем, в обработчике событий Page_Load, у вас есть допустимая и безопасная строка (ASP.NET генерирует исключение в противном случае и не будет пропускать поток кода Page_Load, поэтому вы защищены от хранения XSS в своей базе данных, исключение будет выглядеть следующим образом: " потенциально опасное значение Request.QueryString было обнаружено на клиенте, так же, как если переменная post содержит любые следы XSS, но вместо Request.Form исключение говорит Request.QueryString." ). Это так, если вы включили " validateRequest" (по умолчанию это). Конвейер ASP.NET генерирует исключение раньше, поэтому у вас нет возможности сохранить любые вещи XSS в вашем магазине (базе данных). Отключение его означает, что вы знаете, что делаете, поэтому вам нужно будет реализовать безопасность самостоятельно (путем проверки того, что происходит).
Наверное, можно с уверенностью сказать "да". В любом случае, поскольку вы в большинстве случаев генерируете QueryString самостоятельно (с помощью кода на JavaScript или на стороне сервера, обязательно используйте HttpUtillity.UrlEncode для кода backend и escape для JavaScript). Таким образом, браузер будет вынужден превратить "Это я!". к "Это% 27s %20me% 21". Вы можете обратиться к этой статье за дополнительной информацией о кодировке URL в JavaScript: http://www.javascripter.net/faq/escape.htm.
Пожалуйста, подробно остановитесь на этом, не мог получить то, что вы подразумеваете под "будет запятой-разделять значения, если указано более одного".
Насколько я помню, никто из них не будет. Вам, вероятно, нужно будет вызвать HttpUtillity.UrlDecode/HttpUtillity.HtmlDecode(на основе того, что у вас есть), чтобы правильно получить строку, в приведенном выше примере с помощью "It me!". вы будете делать что-то вроде (см. пример 1 как-то не так с форматированием кода, если я поместил его после нумерованного списка).