IL CODICE:Perché/quando le scritture di sessione sono vulnerabili alla terminazione del thread?
Session["foo"] = "bar";
Response.Redirect("foo.aspx");
IL PROBLEMA:
Quando foo.aspx legge "foo" dalla sessione, non è lì. La sessione è, ma non c'è alcun valore per "pippo".
L'ho osservato a intermittenza nel nostro ambiente di produzione. Ma non intendo qui per chiedere a question about Response.Redirect().
LA SPIEGAZIONE:
Bertrand Le Roy spiega (il grassetto è mio):
Ora, che cosa Redirect fa è quello di inviare un'intestazione speciale al cliente in modo che si chiede al server per una diversa pagina rispetto a quella che stava aspettando. Lato server, dopo aver inviato questa intestazione , Redirect termina la risposta. Questa è una cosa molto violenta da fare. Response.End arresta effettivamente l'esecuzione della pagina ovunque sia utilizzando una ThreadAbortException. Quello che accade davvero qui è che il token di sessione si perde nella battaglia.
Il mio takeaway è che Response.Redirect() può essere pesante con i thread finali. E questo può minacciare la mia sessione di scrittura se si verificano troppo vicino a quella pesantezza.
LA DOMANDA:
Che dire di ASP.NET gestione delle sessioni rende così vulnerabili a questo? Il() Linea Response.Redirect di codice non inizia la sua esecuzione fino a quando la linea di sessione di scrittura è "finito" - come può essere una minaccia per la mia scrittura sessione?
E la scrittura di sessione non "finire" prima della riga successiva di codice viene eseguito? Ci sono altri scenari in cui le scritture di sessione sono similmente (come se non si siano mai verificate) perse?