.NET HttpSessionState tra maiuscole e minuscole

Question

di HttpSessionState utilizzando un "InProc" store sembra trattare di sessione valori chiave delle variabili come case insensitive .NET. Ad esempio:

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

Questo comportamento sembra essere privi di documenti, quindi sto chiedendo se è semplicemente un effetto collaterale del meccanismo negozio sessione sottostante, o intenzionalmente implementata dalla classe stessa. Poiché C# tratta tutto il resto come maiuscole e minuscole, è un po 'snervante per la sessione non agire allo stesso modo. Cosa dà? Differisce per tipo di negozio? È lì per retrocompatibilità con VB?

Answer 1

Le chiavi di HttpSessionState sono state rese insensibili alle maiuscole per soddisfare il comportamento del classico oggetto Session ASP. Ciò ha reso più semplice per gli sviluppatori portare le loro applicazioni ASP in ASP.NET senza introdurre problemi di distinzione tra maiuscole e minuscole.

Lo stesso comportamento della chiave senza distinzione tra maiuscole e minuscole è vero per gli oggetti QueryString, Cookies, ecc. E altri oggetti incorporati ASP simili a Classic.

Ero al team di IIS in Microsoft durante la progettazione di ASP.NET e ASP.NET ha lavorato duramente per mantenere il codice ASP.NET compatibile all'indietro con ASP laddove possibile. Ciò non significa che ASP.NET avesse una perfetta compatibilità con le versioni precedenti, ma ogni volta che veniva presa una decisione (come in questo caso-sensibilità), la risposta predefinita era quella di far corrispondere il comportamento ASP classico a meno che non ci fosse una buona ragione per non farlo.

Detto questo, sono d'accordo sul fatto che l'insensibilità alla causa di Session potrebbe essere meglio documentata.

BTW, la raccolta Sessione ASP.NET ottiene il comportamento del caso da NameObjectCollectionBase che è la classe base per tutti gli oggetti incorporati ASP.NET per cookie, stato sessione, stato applicazione, intestazioni, ecc. Dai documenti:

La struttura sottostante per questa classe è una tabella hash.

Ogni elemento è una coppia chiave/valore.

La capacità di un NameObjectCollectionBase è il numero di elementi della NameObjectCollectionBase può contenere. Poiché gli elementi vengono aggiunti a un NameObjectCollectionBase , la capacità viene aumentata automaticamente come richiesto tramite la riassegnazione.

Il provider del codice hash distribuisce i codici hash per le chiavi nell'istanza NameObjectCollectionBase . Il provider di codice hash predefinito è CaseInsensitiveHashCodeProvider.

Il comparatore determina se due chiavi sono uguali. Il comparatore predefinito è CaseInsensitiveComparer.

In .NET Framework versione 1.0, questa classe utilizza i confronti della stringa sensibile alla cultura . Tuttavia, in .NET Framework versione 1.1 e successive, questa classe utilizza CultureInfo .. ::. InvariantCulture quando confronta stringhe. Per ulteriori informazioni su come cultura colpisce confronti e l'ordinamento, vedere Confronto e ordinamento dei dati di un determinato cultura a confronto e ordinamento dei dati per un Cultureand specifico Performing Cultura-insensitive String Operations.

Una domanda di follow-up ragionevole sarebbe: perché il classico ASP è stato progettato con chiavi senza distinzione tra maiuscole e minuscole? La ragione di ciò è che, nel 1996 (o giù di lì), la lingua principale utilizzata con ASP era VBScript, quindi era logico soddisfare le aspettative insensibili alle maiuscole e minuscole degli sviluppatori di VB.

Answer 2

Mentre C# fa distinzione tra maiuscole e minuscole, questi costrutti in ASP.NET non fanno distinzione tra maiuscole e minuscole perché molto in HTML non fa distinzione tra maiuscole e minuscole (almeno in HTML4 - XHTML è sensibile al maiuscolo/minuscolo o al corso). Credo che questo sia implementato nella classe stessa. È indipendente dal fatto che lo stato sia in-process o altrove.