.NET HttpSessionState Нечувствительность к регистру

.NET HttpSessionState, используя хранилище InProc, похоже, обрабатывает значения ключа сеанса как нечувствительные к регистру. Например:

session["foo"] = 1;
session["Foo"] = 2;
Trace.Write(session["foo"].ToString()); // => 2

Такое поведение кажется недокументированным, поэтому мне интересно, является ли это просто побочным эффектом основного механизма хранения сеанса или намеренно реализуется самим классом. Поскольку С# рассматривает все остальное как чувствительное к регистру, это немного раздражает сессию, чтобы она не действовала одинаково. Что дает? Различается ли он по типу магазина? Это для обратной совместимости с VB?

Ответ 1

Ключи HttpSessionState были сделаны нечувствительными к регистру, чтобы соответствовать поведению классического объекта сеанса ASP. Это упростило разработчикам переносить свои ASP-приложения на ASP.NET, не вдаваясь в тонкие проблемы чувствительности к регистру.

Такое же поведение, нечувствительное к регистру, относится к объектам QueryString, Cookies и т.д. и другим встроенным объектам аналогичного класса.

Я был в команде IIS в Microsoft, когда ASP.NET проектировался и ASP.NET работал трудно держать код ASP.NET обратно совместим с ASP, где это возможно. Это не означает, что у ASP.NET была отличная совместимость в обратном направлении, но всякий раз, когда принималось решение (например, этот чувствительный к регистру), ответ по умолчанию должен был соответствовать классическому поведению ASP, если только не было хорошей причины не делать этого.

Тем не менее, я согласен с тем, что проверка безопасности сеансов может быть лучше документирована.

BTW, коллекция сеансов ASP.NET получает свое поведение от NameObjectCollectionBase, который является базовым классом для всех построенных ASP.NET - в объектах для файлов cookie, состояния сеанса, состояния приложения, заголовков и т.д. Из документов:

Основная структура этого class - хеш-таблица.

Каждый элемент представляет собой пару ключ/значение.

Емкость NameObjectCollectionBase - это номер элементов NameObjectCollectionBase может содержать. В виде элементы добавляются к NameObjectCollectionBase, емкость автоматически увеличивается по мере необходимости через перераспределение.

Поставщик хэш-кода передает хэш коды для ключей в Экземпляр NameObjectCollectionBase. поставщик хэш-кода по умолчанию - это CaseInsensitiveHashCodeProvider.

Сравнитель определяет, будут ли два ключи равны. Сравнение по умолчанию это CaseInsensitiveComparer.

В .NET Framework версии 1.0 это класс использует чувствительную к культуре строку сравнения. Однако в .NET Рамочная версия 1.1 и более поздняя. использует класс КультураInfo..::. Инвариантная культура, когда сравнение строк. Для большего информация о влиянии культуры сравнения и сортировки, см. Сравнение и сортировка данных для определенного Культура Сравнение и сортировка данных для Конкретная культура и исполнение Нечувствительные к строкам строки.

Разумным последующим вопросом будет: почему был классический ASP, разработанный с нечувствительными к регистру ключами? Причиной этого является то, что еще в 1996 году (или около того) основным языком, используемым в ASP, был VBScript, поэтому имело смысл учитывать нечувствительные к регистру ожидания разработчиков VB.

Ответ 2

В то время как С# чувствителен к регистру, эти конструкции в ASP.NET не чувствительны к регистру, потому что в HTML нечувствительны к регистру (по крайней мере, в HTML4 - XHTML чувствителен к регистру или курсу). Я считаю, что это реализовано в самом классе. Он не зависит от того, находится ли государство в процессе или где-либо еще.